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3.0 CJPCI DESCRIPTIONS 



o 



This section presents requirements for tJie governraent specified idiysicad 
interface and CPCIs FTP, SffTP, and DDN Gatewa^?^. It also presents the 
required NOS and-DCNS version/level and all required modifications to WS and 
DCNS, including -X. 25. Only the system interfeu^e requirements for the CPCIs 
IP, EGP, TCP, and TELNET are givesi in this section; , full external and 
protocol specifications for tlisse CPCIs are given in separate ERSs (refer to 
section 2). , 

3.1 Physical Interface 

3.1.1 Physical Interface Abstract 

The i^iysical interface provides the actual electrical connectivity between 
the CYBER host, tenninsils, and the DDN, 

^^ 3.1.2 Physical Interface Description ^^ 

The physical interface consists of four distinct interfaces: the. interface 
to a; DDN PSN, the terminal interface, the inter-DI interface, and the CYBER 
interface. All physical interfaces are implemented losing standsuxl CDCNET 
hardware and software with no changes required for DIM. Itefer to sections 
3.11 and 3.12 for descriptions of the CDCTMET hardwara CI and software CPCI. 

3.1.2.1 DDN PSN Interface <XHIF 2.4, XHIF App.By IMP Aipp,3) 

*nie ^ysical interface to a DDN PSN shall adhere to the requirements of the 
DDN X.25 Host -Interface Specification (XHIF) and the Specification of the 
Interconnection rBetween a Host and ers IMP (IMP). The physical interface to a 
DDN PSN shall ]be"provided by the 2610-16 Line Interface Module and 2610-150 
cable. 

o o 
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^j a. The protcxsol shall be RS-449 Balanced. 

b. The connector type shall be DB37. The optional 9-pin connector is 
not used. 

c. The operating mode shall be DTE, with DCE mode provided by the PSN 
or modan. 

d. The DCE connection shall be either direct connection or via modem. 

e. Line rates of both 56Kbps and 9.6 Kbps, in two directions 
simultaneoiisly (full-duplex), shall be si-^jported. 

f. The LIM shall reside in the NDI. 

3.1.2.2 Terminal Interface 

^ The physical interface to terminals shall be provided by the 2612-1 Line V^^ J 
Interface Module and 2612-550 cable. 

a. The protocol shall be RS-232. 

b. Ilie connector type shall be DB25. 

c. The operating mode shall be DCE, with DTE mode provided by the 
terminal. 

d. Line rates of .SICbps, 1.2Kbps, and 9.6Kbps, at a minimum, shall be 
supported. 

e. Standard CDCNET terminal types shall be supported, including XTIOO, 
CDC-721, and basic Teletype. 

f. The LIM shall reside in the TDI. 

G C 
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1'^, 3.1.2.3 Inter-DI Interface f^ 

The physical interface for DI inter-connection shall be provided by the 
2608-1 Ethernet Serial Channel Interface and 2608-110 transceiver cable. 

a. Ihe transceiver interconnections shall be provided by the Ethernet 
Transceiver and Ethernet cable, or by the 2631-1 Ethernet 
multiplexor. 

b. The pAiysical protocol shall be TT?kf 802.3 CSMA/CD. 

c. The link-level protocol shall be IEEE 802.2 Link. 

d. The ESCI shall reside in the MDI, the NDI, and the TDI. 

3.1.2.4 CYBER Interface .f.e 

f% The physical interface to the CYBER shall be provided by the 2607-001 ' ''^ /^ 
Mainframe Channel Interface and CYBER perijiieral channel cable. iii; 

a. The MCI shall reside in the MDI. 

3.2 X.25 

3.2.1 X.25 Abstract 

X.25 provides network-level access to the DDN PSN, and shall use RS-449 for 
the physical ax^cess. 

3.2.2 X.25 Description 

The X.25 protocol provides network access to the DDN PSN and consists of the 
X.25 link level and X.25 packet level protocols. The standard CDCNET HDLC, 
X.25 Packet Level, and X.25 Network Solution software shall be used, with 
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/ >s ">i"or modifications required for compliance with DDN specifications. The ^-^ 
V / X.25 protocols shall reside in the NDI. Figure 3.2-1 depicts the vsirious \J^ 

X.25 components and their relationship to other DDN CYBER host interface and 

CDCNET components. 

Since the size of modifications to X.25 is insufficient to justify a separate 
IDS document, the detailed design for these modifications is incorported into 
the ERS, in section 3.2.4. 

3.2.2.1 X.25 Link Level Protocol (XHIF 1.2.1, 2.3) 

The X.25 link level protocol shall be provided by the CDCNET High-level Data 
Link Ciontrol (HDLC) Stream Service Routine (SSR) and CIM controlware. 

3.2.2.1.1 HDLC Protocol (XHIF 1.2.1, 2,3) 

The protocol shall adhere to the requirements of the DDN X.25 Host Interface 
Specification (XHIF). No changes are required to CDCNET to support the DDN 
'^ J requirements for this protocol. v 

a. The HDLC procedure shall be Line Access Procedure/Balanced (LAEB) . 

b. The protocol shall support line rates of both 9.6Kbps and 56Kbps 
fxill-duplex. 

3.2.2.2 X.25 Packet Level Protocol (XHIF 1.2.1, 2.1, 2.2) 

The X.25 packet level protocol shall be provided by the CDCNET X.25 Packet 
Level module and the X.25 Network Solution module. The protocol shall adhere 
to the requirements of the DDN X.25 Host Interface Specification (XHIF). The 
supported sersdce type shall be DDN Standard X.25. 



N 
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(2) Caianges to CDCNET X.25 to support DDN fall into the following functional \J) 

areas: 

a. X.25 Network Solution support of the X.25 facility for DDN Standard 
service. 

b. X.25 Network Solution support of the X.25 facility for DDN 
precedence. 

c. X.25 Network Solution suppression of CDNA-specific data in the X.25 
Call -User-Data on DDN circuits. 

d. X.25 Network Solution suppression of CDNA-specific 3A header in X.25 
data packets. 

e. X.25 Packet Level stjpport of the X.25 diagnostic packet. 

^^ The requirements for the above changes are given in the following \j) 
subsections. 

3.2.3 External Interfaces 

The following subsections define the X.25 external interfaces for the DDN 
project. Since X.25 is a standard CDCNET prodixit, the only interfaces 
specified are those that must be modified or those that affect sj^tsn 
interface testing. 

3.2.3.1 X.25 Network Configuration 

The operational parameters for CDCNET X.25 are configured via operator 
COTBiiands. The following subsections specify the changes required to these 
cranmand processors for DDN X.25. Additionally, values for existing 
parameters are specified vAiere required by the design. Parameter values that 
are required by the DDN connection but are not required by the design are 
■ J) specified in section 3.2.8.1. B^ 
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( "\ 3.2.3.1.1 Precedence Parameter (XHIF A-3,2-4) 



o 



The Define_X25_Network comraand processor shall be extended to allow 
specification of DDN precedence (refer to AEJH6785, Network Definition, sec 
9.5.4). 

a. A parameter shall be defined called DDN_X25_Precedence (alias dxp) . 

b. The permitted values for the dxp parameter shall be in the range 
to 3. 

3.2.3.1.2 Protocol ID Parameter (XHIF 2.1.3) 

Ihe Define_X25_Network command processor shall be used to specify the DDN 
protocol id. No changes to the standard CDCNET X.25 are required to support 
this parameter (refer to ARH6785, Network Definition, sec 9.5.4). 

a. The network_protocol_id parameter shall be specified with a value of 
CC(16) for DDN Standard X.25 circuits. 

b. The value of npi shall be used to identify DDN specific processing 
as defined in later subsections. 

3.2.3.1.3 Architecture Tyi)e Parameter 

The Define_X25_Network consnand shall be used to specify the supported network 
architecture. This parameter identifies the network 8ux;hitectures to be 
supported by the network solution, and can be cdna, dod, or both. No changes 
to the standard CI)CNET X.25 are required to support this parameter (refer to 
ARH6785, Network Definition, sec 9.5.4). 

(Note that this feature is present in (3X3^ET level 1704, but is not a 
documented or supported feature at this level. This does not affect DDN 
implementation, but may effect PSR support during test.) 
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a. The architecture_type pai'ameter shall be specified with a value of 
'dod' for DDN Standard X.25 circuits. 

b. The value of at shedl be used to identify DDN specific processing, 
as defined in later subsections. 

3.2.3.1.4 PDN Name Parameter 

The Define_X25_Interface command shall be used to specify the DDN pdn name. 
No changes to the standard CDCNET X.25 are required to support this peirameter 
(refer to ARH6785, Network Definition, sec 9.5.5.2). 

a. The pubiic_data_network peirameter shall be specified with a value of 
'DDNJSTANDARD' for DDN Standard X.25 circuits. 

b. The value of pdn shall be vised to identify DDN specific processing 

^ as defined in later subsections. ^^^ 

o o 

3.2.3.2 X.25 Peer Protocol (XHIF 1.2.1, 2.1, 2.2) 

The X.25 modules shall conduct the peer protocol with a DDN packet switching 
node. The following subsections specify the changes required to the X.25 
protocol implonentation for DDN X.25. 

3.2.3.2.1 X.25 Private Facility for DDN Standard {XHIF 2.1.2.1) 

DDN X.25 defines a special private facility that must be specified if a 
virtual circuit is to utilize DDN Standard X.25 service. Standard service 
implies that the X.25 link is terminated at the PSN, and all subsequent 
routing is done using DDN Internet Protocol. Standard service is available 
only vAien IP is used for the 3B layer. 

The X.25 Network Solution module shall be modified to support the DDN 
_ Standard call feu^ility. ^^_ 

o © 
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^ \ a. The call facility shall be included in the CALL REQUEST packet if 
^ ^ and only if the associated interface was configured with 

pdn=DDN_STA>JDARD and the associated network was configured with 

npi=0C(16). 

b. The call facility shall be two octets in length with the value 
0401(16). 

3.2.3.2.2 X.25 Private Facility for DDN Precedence (XHIF 2.1.2.2) 

DDN X.25 defines a special private facility that allows a host to select a 
non-default precedence for the virtual circuit. This precedence vadue 
determines the priority given to one user circuit over another during heavy 
load conditions. 

The X.25 Network Solution module shall be modified to support the DDN 
Precedence call facility. 

'^ '' a. The call facility shall be inclxxied in the Call Request and Call ^^ 
Accept packets if and only if the associated network was configured 
with the dxp peurameter specified. 

b. The call facility shall be two octets in length with the value 
080n(16) where n is the value specified in the dxp parameter. 

3.2.3.2.3 CDNA User Call Data (XHIF 2.1.3) 

The cvirrent X.25 Network Solution server passes a CDNA-specific block in the 
user-call-data portion of the Call Request and Accept packets that is tised by 
the remote network (assumed to be CDNA) to select the appropriate network id 
with vAiich to associate the virtual circuit. DDN Standard X.25 neither sends 
this block, nor recognizes such a block when received. The block is not 
reqviired for a DDN Standard X.25 network solution because the associated 
network id is alwaj^ unambiguous. 

o o 
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The X.25 Network Solution module shall be modified to siippress CDMA-specific 

data for DDN Staraiard X.25 networks. 

a. Tlie CDNA Call User Data Block shall be sent with the Call REQUEST 
packet if and only if the aissociated interface wais configured to 
support the cdna architecture type (at=cdna or at=(cdna,dod) ) . 

b. The protocol id field of the &ill User Data Block sheill be sent even 
for DDN connections. 

c. The CDNA Call User Data Block shall be fabricated for inccxning Call 
Request or Call Confirm packets if and only if the associated 
interface was not configured to support the cdna architecture tyj)e 
(at=dod). 

d. The CDNA Call User Data Block shall be fabricated with the following 

gy^ information (refer to ARH6211, CDCNET X.25 Interface, sec 5.7.2): g%. 

1. Ihe DI System ID shall be of the form 0800250nnnnn(16) vdiere 
nnnnn are the 5 right-most hexadecimal digits of the assigned 
network id specified in the X25 network configuration consnand 
(refer to ARH6836, CDCNET Titles and Addresses, sec 8.2.2). 
This ID is used for consistency and identification, and should 
not be used by CDNA modules; the address must be regarded as a 
foreign network host. The number has been chosen such that it 
will not collide with other system addresses as long as the 
network id's assigned to DDN connecticwis are no more than 5 
digits. 

2. The Network ID shall be the network id specified in the X.25 
network configuration command (refer to ARH6785, Network 
Definition, sec 9.5.4). 

o o 
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v) 3.2.3.2.4 CDMA 3A Header \J) 

Intranet 3A currently appends a header to all data bl(x;ks sent over an X.25 
network solution, and expects all data blocks received to contain the 
header. This header follows the same format as the IEEE 802.2 link level 
header (refer to IEEE standard 802.2-1985), and is used to identify the 
destination SAP (that is, protocol id of 3A ULP) . DON Standard X.25 neither 
sends this header, nor recognizes such a header when received. "Die header is 
not required for a DDN X.25 network solution becaxise the associated SAP is 
always unambiguous - it is always the IP SAP/protocol id. 

The X.25 Network Solution module shall be modified to suppress the 3A header 
on data jackets destined for DDN Standard X.25 networks. 

a. Tlie C3)NA 3A header shall be sent with a data packet if and only if 
the associated interface was configured to log the cdna architecture 
type (at=cdna or at=(cdna,dod)) . 

o ■ o 

b. The CDNA 3A header shall be fabricated for inccnning data packets if 
and only if the Eissociated interface was not configured to support 
the cdna architecture type (at=dod) . 

c. Hie 3A headers shall be stripped or added only for the first packet 
of each X.25 complete message, since only those packets contain the 
3A headers. 

d. The CDNA 3A header shall be fabricated with the following 
information (refer to ARH6694, IEEE 802 Support and CDtiA Layer 3a 
Headers ) . 

1. Ihe Destination SAP field (DSAP) shall be set to the IEEE- 
assigned IP protocol id. The value of this protocol id is 
96(10) (refer to RFC-948, Transmission of IP Datagrams over IEEE 
802.3 Networks). 

o o 
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j 2. The Source SAP field (SSAP) shall be set to the same value as \J 

the DSAP field j( refer to 1 above). 

3. The control field shall be set to zero. 

3.2.3.2.5 X. 25 Diagnostic Packets (XHIF 2.2-6) 

DDN X.25 sends diagnostic psickets vdien certain errors are detected by the 
DCE. The DCE expects these padtets to be accepted without response or 
action. CDCNET X.25 discards diagnostic packets without notice, so that an 
administrator will not know if such a packet is received. 

The X.25 Packet Level module shall be modified to support diagnostic packets 
frcMi the DCE. 

a. Received diagnostic packets shall be logged using standard CDCNET 
logging facilities. 

b. No other action shall be taken in response to a diagnostic packet. 
No ULP indications shall be sent, no response shall be sent to the 
X,25 peer, no requests shall be made to the HDLC layer, and no 
changes shall be made to the internal state variables for the 
associated virtual circuit. 

3.2.3.3 Log Messages 

X.25 shall provide log messages for operations and network analysis using the 
Log M-E interface. The standard X.25 modules currently generate several 
messages. Ilie following additional messages shall be generated to support 
the DDN interface. 



. v_.v 






o 
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3.2.3.3.1 X.25 Packet Level Log Messages 



o 



LOG MESSAGE PURPOSE 

This message indicates that the X.25 Packet Level received a 
diagnostic packet. 

ACTION REQUIRED 



None. 



DESCRIPTIVE MESSAGE 



! M A S K I 


! L G _ 


.MESSAGE_BUFFER I 


1 fixed text } 


1 type 


[value ! description | 


! See Mask 1 | 


1 char 


! 1..31 IX. 25 Interface Name | 


I below 1 




■ • 1 

■ 1 1 

— ^— —• -*•— »»4— »— — «.«.«.»i 1 


! See Mask 2 I 


! int 


I 0..255 I Diagnostic code I 


I below 1 




II 1 
II t 


; See Mask 3 ', 


I int 


! 0..3 ! Number of explanation bytes | 


! below I 




1 I 1 
1 1 1 


1 See Mask 4 | 


j binsiry 


I 3 bytes I Diagnostic explanation bjrtes ! 


{ below 1 


1 octets 


II 1 
II I 

-+ + 1 



maskl - 'X.25 Diagnostic packet received on Interface Name =* 

niask2 - 'Containing Diagnostic code =' 

inask3 - 'with number of Explanation bytes =' 

mask4 - ', Explanation =* 



o 



o 
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(])[TEMPLATEIDs (Q) 

I 

[ XPETEMP 

[ 
[ 
[LOG MESSAGE ID and LOG MESSAGE ATTRIBUTES 

CONST 

xpl$diag_packet_received = inin_log_inessage_id + 1147; 
[ EL 



3.2.3.4 Intranet 3A 

X.25 shall provide the interface to the ULP via the CDMA Intranet 3A module. 
This module shields the details of the specific network solution from the 
ULP. No changes are required to Intranet to support DDN X.25. However the 






J architecture(_type feEiture, which is not a formal part of the CDCNET release v 

for the DDN baseline (release 1.1), is required. 

3.2.3.5 Internet Protocol 

X.25 shall provide a network solution interface to the Internet Protocol. 
This interface is provided transparently via the CDNA Intranet 3A module. No 
changes are required to X.25 to support the IP ULP. 

3.2.3.6 HDLC 

X.25 shall use the CDCNET HDLC SSR ULP interface for the link-level interface 
with the remote X.25 peer. No changes are required to HDLC to support DDN 
X.25. 
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\J) 3.2.4 Internal Interfaces %J) 

The following subsections present the detailed design for the modifications 
to CDCNET X.25. Changes to common data definitions are given in section 
3.2.6. In some cases, the design for the entire module to be changed is 
given. New lines are marked by a plios sign (+), modified lines are marked by 
an asterisk («), and lines that have simply changed indentation (for example, 
because an IF statement was inserted) are marked by a minus sign (-). In 
other cases, only a fragment of the existing module along with the identified 
changes, or a description of the area to be changed, will be given; in these 
cases, a deck/line number reference is given in brackets. 

The modifications are made to three separate CDC!NET nKxlules: 

1) X25 Network Solution CcMimand Processor Module [XNMCMDP] 

2) X25 Network Solution Searver Module [XNMX25N3 

3) X25 Packet Level Module [XPMPLC] 

o o 

3.2.4.1 X25 Network Solution Command Processor Module 

"Die X25 network solution ccHnmand processor is modified to accept the new DDN 
precedence parameter, "nje following procedures are modified: 

1) C3nd_define_x25_net 

3.2.4.1.1 crod_define_x25_net Modifications 

The following changes are made to this procedure: 

a) Before the parameter loop /defxn_parm_loop/, and after parm_index is 
initialized, the ddn_precedence item will be initialized to 
'unspecified'. [XNMCMDP.434] 

O O 
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vJ' b) At the end of the parameter case statement (after the pann_at case), ^' 
a new case statement will be added called parm_dxp. The body of the 
case will set the ddn_precedence item to the value of the 
parameter. [XNMCMDP.488] 

3.2.4.2 X25 Network Solution Server Module 

The X25 network solution server is modified to handle the DDN Standard and 
DDN precedence facilities, and to manage CDNA-specific headers, for DDN 
Standard networks. The following procedures are modified: 

1) Data Structures 

2) send_call_request 

3) x25ns_layer_management 

4) x25ns_connection_management 

5) x25ns_data_indication 

6) process x25ns event 

V / 7) build_facilities (new procedure) Vy 

8) validate_facilities (new procedure) 

3.2.4.2.1 Data Structure Modifications 

The following changes are made to X.25 network solution data structures: 

a) Add a new data structure to handle facilities processing. 
[XNMX25N.129] 

/ OC»fST 

privatejfacilityjnarker = 0; 
fac_ddn_precedence_code = 08(16); 
fac_ddnjprecedence_parm = Oj 
fac_ddn_standard_code =04(16); 
f8u;_ddn_standard_parm =1; 
fac_fast_select_code =1; 
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fac_fast_select_parm = 80(16); 
fEUD_reverse_charge_code =1; 
fac_reverse_charge_parm = 1; 

VAR 

facilities: [STATIC] packed record 
length: .. 255, 

list: array [1 .. 32] OF packed record 
code: .. 255, 
parameter: .. 255, 
recend, 
recend; 

b) Add an additional clear-request diagnostic code for facility- 
processing. [XNMX25N.86] 

cr_none =0, 
(y + cr_invalid_facility = 41(16); \J) 

cr_peer_first =90(16), 



etc. 

3.2.4.2.2 send_call_request Modifications 

The following changes are made to this procedure: 

a) A new procedure called build_facilities is csilled to build the 
facilities block, which can include the DDN Standard and Precedence 
facilities. 



(6443W/WP33) CCMTBOL DATA HRTVATE 3-16 



HKSYSlM-OOa-ERS-OO-C 
^ 10 December 1986 

'''^'-^ b) The CDNA call request data is not sent if the packet is destined for ^^ 

a foreign network (for example, DDN Standard). [XNMX25N.679] 

Begin Procedure 

Call apperai to add remote dte address to packet 

* Call build_facilities to handle accept_pdn_charges and DDN 

facilities 

Call append to add the facilities block to the data packet 

Set the protocol id into the user data 

Set the system and network id into the user data 
+ IF architecture_type does not include cdna THEN 
+ Set user data length to one byte (for protocol id) 
+ ELSE 

+ Set user data length to size of user_data record, 
+ to include cdna connection information 

* Call append to add the user data to the packet, 

X X * using user data length ^ n 



V. y 



O 



. [remainder of procedure] 

* 

PROCEND; 

3.2.4.2.3 x25ns_layerj[nanageraent Modifications 

The following changes are made to this procedure: 

a) If the user data does not match the expected cdna length, an 
incoming call request currently is rejected. This is changed so 
that the list of networks (Network Information Block chain, nib) is 
searched for a foreign (that is, not CDNA architecture) network that 
matches the calling ETE address and protocol id. If one is found, 
the facilities are checked for correctness and the call is accepted. 
[XNMX25N.926] 
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o 



CASE of indication type 



= pl_call_indication = 



o 



Call get_f irst_byte to extract address length frcMn block 

* Call strip to get calling dte address and save locally 
+ Call strip to get called dte address 

Call get_first_byte to get facilities length 

* Call strip to get facilities block, saving in the new global 

* facilities record 
+ Call strip to get user data block, saving in global user 

data recoiTd 

« IF length of user data is not equal to expected cdna size 
TEffiN 
Search list of nib's for network with id that matches 

user data 
IF nib NOT found THEN 

Set clear reeuson to cr_network_ide_not_def ined 
ELSE 

Verify network is X25, reverse charges are correct, sap 
is 
correct 

+ IF call request does match cdna requirements THEN 

+ [that is, if clear_reason is not cr_none] 

+ Loop through nib chain, searching for network with the 

+ following characteristics: 

+ a. calling dte address matches nib remote dte 

address 

+ b. user data protocol id matches nib protocol id 

+ c. nib a]7chitect\Jire_type does not inclxxie cdna 

O © 
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^--^ + IF network not found THEN ^^ 

+ Set clear reaison to cr_incorrect_data_length 
+ ELSE network found 

+ Call validate_facilities to evaluate inbound facilities 
+ IF facilities are vedid THEN 

+ Set the network id in txser data record to value in lib 
+ Set the system id in user data record to broadcast 

address 
+ since actual system id is unknown - this will 

cause 
+ all call collisions frcsn foreign architecture 

networks 
+ to always resolve in favor of the incc8iiin£ call. 

+ 

IF clear_re8uson is cr_none THEN 

/^ X . (remainder of procedure) ^ ^ 

EROCEND; 

3.2.4.2.4 x25ns_connection_management Modifications 

The following changes are made to this procedure: 

a) A 3A header is created and prefixed to the data buffer before 
sending it to Intranet, if the network is not a cdna architecture. 
[XNMX25N.1050] 

Begin Procedure 

Set pointer to link_interface_block (lib) 
IF indication is a data indication and link is active THEN 
+ ' IF architecture_type does not include cdna THEN 
+ Set local 3A header DSAP and SSAP fields to DDN IP 



V J 
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+ protocol id (96) 

+ Call prefix to add 3A header to buffer 
Call 3A to deliver data buffer 
ELSE 

• 

. [remainder of procedure] 

F5R0CEND; 

3.2.4.2.5 x25ns_data_indication Modifications 

Ilie following changes are made to this procedure: 

a) The 3A header is stripped from the data buffer before sending it to 
the packet level module, if the network is not a cdna architecture 
network (that is, DDN Standard network) . [XNMX25N.1174] 

V/ Begin procedure \j^ 

Get data buffer pointer 
IF link is not active THEN 

Discaiti message and issue log message 
ELSE 
+ IF architecture_type does not include cdna THEN 
+ Call strip to ranove 3A header 
Issue packet level data request 
IF data request rejected THEN 
Issue log message 
PROCEND; 



o c 
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xj 3.2.4.2.6 process_x25ns_event Modifications O 

The following changes are made to this procedure: 

a) A call is made to the new build_facilities procedure for the case 
when a call_accept packet is sent. [XNMX25N.1297] 

t ========================= 

= nsa_accept_call_ns_up = 
[ ========================= 

Set packet level request type 
Set packet level CEPID 
Clear D-bit in request 
* Call build_facilities to handle DDN facilities 
Set request block size 
Issue call_aiccept request 

. [remainder of procedure] 

PROCEND; 



i , 



o 
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3.2.4.2.7 New Procedure build facilities 



o 



A new prcKiedure is defined that builds facilities to be sent in a Call 
Request or Call Confirm packet. 



o 



^ttttttt * t * * * * * tt****** t * tttttKtt 

PROCEDURE mm: BUILD _ FACILITIES 

PURPOSE: 

Build facilities block for Call Request/Confirm packets. 

DESCRIPTIW: 

The facilities block for a pE«3ket is generated for Call 
Request and Call Confirm packets, based upon network 
configuration information. 



INPUTS: 
lib_ptr 
action 



''x25ns_lib_type PI: lib pointer 
range_of_x25ns_actions P2: action to take 



PROCEDURES REFERENCED 

OUTPUTS: 
facilities 



GL: global facilities block 



ie*tt******t*t*t*ttt**ttt**t****** 



1> 



PROCEDURE build_facilities ( [ 

lib_ptr: ''x25ns_lib_t3Tje; [ 
action: range_of_x25ns_actions) ; 
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VAR 

count : . , 255 , 
privatejmarker: .. 255; 

[ 
[ * » * BUILD STANDARD X25 FACILITIES. 
[ 

Set local fauDility count to zero 

IF action is nsa_accept_call_ns_up THEN 
IF accept_pdn_charges THEN 

Set facilities. list[cotint] .code to fac_reverse_chsLrge_code 
Set f acilities. list [count 3 .pann to fac_reverse_charge_parm 
Increment count 

[ 

[ * » * BUILD PRIVATE X25 FACILITIES, IF ANY, AFTER FACILITIES MARKER. 
I 

Set facilities. list[count] .code to private_facility_inarfcer 

Set facilities. list [count] .pann to private_facility_inarker 

Set private_inarker to count 

IF pdn name is "DDN_STANDARD" AND protocol id is ddnjstandard THEN 
Set facilities. list [count+1]. code to fac_ddn_standard_code 
Set f acilities. list [count+1 ] .pjarm to fac_ddn_standard_pann 
Increment count 

IF ddn precedence is NOT unspecified THEN 
Set facilities. list[count+l] .code to fac_ddn_precedence_code 
Set facilities. list [count+1 3 .parm to fac_ddn_precedencejparm + 

value of configured ddn precedence 
Increment count 
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IF count is not equal to private_inarker THEN 
[that is, private facilities exist] 
Increment count 
Set facilities . length to count * 2 + 1 



o 



raOCEM) build_facilities; 



3.2.4.2.8 New Procedure validate facilities 



A new procedure is defined that validates facilities received in a Call 
Request packet. 



o 



o 



PROCEDURE NAME: VALIDATE_FACILITIES 

PURPOSE: 

Validate feu^ilities received in a Call Request packet. 

DESCRIPTICW: 

The facilities block for a packet received in a Call 
Request is compared to configured information. A clear 
reason code is returned if any facilities conflict 
or are unrecognized. 



INPUTS: 
lib_ptr 
facilities 



*x25ns_lib_type PI: lib pointer 

GL: global facilities block 



PROCEDURES REFERENCED 

OUTPUTS: 

clear reason . . 255 



P2 : clear recison code 



t*t*tt******tt*ttt**t***** * * t * t t * 
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PROCEDURE build_facilities ( [ \J 

lib_ptr: ''x25ns_lib_type; [ 
VAR clear_re£ison: .. 255); 



[$ 



VAR 

count: .. 255, 
private_facilities: boolean; 

Set clearjreason to cr_none 
Set private_facilities to FALSE 

Loop through facilities block, using count as the index frcm 
to ( facilities. length-l)/2 DO 

[ 

[ * « * VALIDATE PRIVATE FACILITIES. 
[ 

IF private_facilities THEN 

CASE of facilities. list [count] .code 



V.,'' 



= fac ddn standard code = 



IF pdn name is NOT "DDN_STANDARD" OR 

protocol id is NOT ddn standard OR 
suxjhitecture type does not include dod (M 
architecture type includes cdna THEN 
Set clear_re8ison to cr_invalid_facility 



= fac_ddn_precedence_code = 
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IF configured precedence is NOT unspecified AND 

configured precedence is NOT equal to facility value THEN 
Set clear_reason to cr_invalid_facility 

ELSE 

Set clear_reason to cr_invalid_facility 

CASEND; 

[ 

[ « » « VALIDATE STANDARD FACILITIES. 

[ 

ELSE 

CASE of feu^ili ties. list [count] .code 

t =========================== 

Ip = private_facility_niarker = \^ 

[ =========================== 

Set private_facilities to TRUE 

[ ================================================= 

= fac_reverse_charge_code, fac_fast_select_code = 
[ ================================================= 

; [ These facilities are handled by X25 packet level 

ELSE 

Set clearjreason to cr_invalid_facility 

CASEND; 

FROCEND validatejFacilities; 

o o 

(6443W/WP33) CONTROL DATA raiVATE 3-26 



HKSYSTM-003-ERS-OO-C 
10 Decerrfcer 1986 



""\, 



3.2.4.3 X25 Packet Level Module 



o 



The X25 packet level module is modified to log diagnostic packets. The 
following procedures are modified: 

1) data structures 

2) log_pl_error 

3) ssr_data__ind_proc 

3.2.4.3.1 Data Structure Modifications 

The following changes are made to X.25 packet level data structures: 

a) Add log message to list of message constants. CXPMPLC.1197] 

xpe_circuit_statistics = 6, 
+ xpe_diag__packet_received = 7, 
\^_y * xpe_last = xpe_diag_packet_rec8ived; -^ y 

b) Add new log message case to log_record_type. [XPMPLC.1221] 

+ = xpe_diag_packet_received = 
+ diag_code: .. 255, 
+ expl_si2e: . . 3, 
+ explanation: .. Offffff, 
casend, 
recend; 

c) Add new log message preset to pl_tenplate__id. 
[XMPMPLC . 1233>AC1D758 . 109] 

* [xpe$circuit__statistics, >q3l$circuit_statistics, 

FALSE, TRUE], [ 
+ [xpe$diag_packet_received, xpl$diag_packet_received, 
(Q TRUE, TRIE]]; Q 
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\y 3.2.4.3.2 log_pl_error ^kxiifications \.J 

The following changes are mside to this procedure: 

a) A new case itan is added at the end of the case statement for the 
new log message. tXPMPLC.4863] 

+[ ============================ 

+ = xpe_diag__packet_received = 
+[ ============================ 

+ 

+ Call gen_data_f ield to put diagnostic code into log 

buffer 
+ Call gen_data_field to put explanation length into log 

buffer 
+ Call gen_data_f ield to put explanation bytes into log 
^^ buffer -^ 

o . o 

ELSE 
RETURN 

3.2.4.3.3 ssr_data_ind_proc Modifications 

The following changes are made to this procedure: 

a) The case item for diagnostic packets is extended to call 
log_pl_error to log the diagnostic packet information. 

[ ================== 

= diagnostic__pkt = 
[ ================== 



o o 
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Vj^ + Call strip to get diagnostic code frcm packet, and pit \J' 

into log record. 
+ CJompute explanation size from message size (msg_size) 

minus fixed 
+ header size (4 octets), and put into log recoiti. 
+ Call strip to get explanation bytes from packet, using 

explanation 
+ size, and put into log record. 
+ Call logjpl_error to log diagnostic packet. 
Call release_message to discard packet 
RETURN 

3.2.5 Errors and Error Recovery 

Standard CDCNET X.25 HDLC, Packet Level, and Network Solution level error 
recovery shall be employed. Support of diagnostic packets shall be as 
specified in 3.2.3.2.5. 

3.2.6 Data Structures 

The following subsections define the changes required to common CDCNET data 
structures to support DDN Standard X.25. The data structures to be changed, 
and the deck they reside in, are: 

1) X.25 DTE Control Block (CMDLIBX) 

2) PDT for Define_X25_Net (XNDDEXN) 

3.2.6.1 X.25 DTE Control Table (CMDLIBX.31) 

One iten will be added to the X.25 DTE Control Table. The itan will contain 
the DDN Precedence, and will be set by the coinnand processor using the value 
specified in the DEFXNf canmand; a special value is defined to recognize when 
the parameter is not specified. The new definitions are shown below. 



o 



v.y 
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x25_dte_ta.ble_type = record 
(existing definitions) 

• 

ddn_precedence: (null, low, medixjm, high, unspecified), [ddn 
precedence 
recend; 

3.2.6.2 PDT for Define_X25_Net (XNDDEXN.3) 

A new parameter description will be added to the end of the parameter 
descriptor table (FDT) for the DEFXN command. The new description is shown 
below. 

I pdt cmd_defxn_pdt ( 

• 

\^ . (existing definitions) \J? 

[ ddn_x25_precedence,dxp: integer 0..3 = $optional 
t ) 

The PDT must be re-run through the FDT pre-processor to re-generate the CYBIL 
definitions in the r^iainder of XNDDFXN; the new definitions must replace the 
existing ones. 

3.2.7 Equipment Ckxnfiguration 

The X25 module, and the above specified modifications, are designed to run in 
a GDCNET DI that is configured with at least one CIM and one LIM v*iich 
provide the physical X.25 connection. Although the X25 module and 
modifications are not designed for a specific physical interface, the 
interface specified in section 3.1 at a minimum shall be supported. 

o o 
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Q 3.2.8 Installatioix Q 

The following subsections define the installation procedtires and parameters 
for the X.25 modif cations CPCI. 

3.2.8.1 X.25 Installation Procedure 

The X.25 modifications are placed into the CDCNET systan using the standard 
DDN/CDCNET update procedures defined in section 3.10.8, The PL used as input 
to the procedures is X25nnnn, v*iere nnnn is the CDC3«IET level number to vAiich 
the transmittal applies. The installation procedure must be run after any 
other CDCNET modifications installation procedures, as specified in section 
3.10. 

3.2.8.2 X.25 Installation Parameters 



N 



No installation parameters are defined for the X.25 modifications. 



3.2.8.2 X.25 Network Configuration 

The following subsections define the DDN-specific requirements for the 
configuration of the X25 interface. 

3.2.8.1.2 Link Level Operational Parameters (XHIF 2.3) 

The Define_X25_Trunk conmand shall be vised to specify the X25 link level 
operational parameters (refer to ARH6785, Network Definition, sec 9.5.5.2). 

a. The mode parameter shall be set to DTE. 

b. The max_unack_frames (K) parameter shall be set to 7. 

c. The pf_recovery_timer (Tl) parameter shall be set to 3000 ms. 
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d. The retransniission_liinit {N2) parameter shall be set to 20. 

e. The trunkjspeed jjarameter shall be set to 9600 or 56000, depending 
upon the link speed. 

f . The clocking parameter shall be set to EXTERNAL. The LIM cannot 
provide clocking for a 56Kbps link. 

3.2.8.2.2 Packet Level Operational Parameters (XHIF 2.1.1, 2.2) 

The Define_X25_Interface and Define_X25_Network conffliarais shall be used to 
specify the X25 packet level operational jjarameters (refer to ARH6785, 
Network Definition, sees 9.5.4, 9.5.5.2). 

a. The remote_dte_address, local_dte_address, pvc_range, inonly_range, 
twoway_range, outonly_range, and defavilt_window_size parameters 

^-^ shall be set to the values eissigned by DCA. ^n*. 

k) ; U 

b. The packet_sequence_numbering parameter shall be set to NORMAL. 

c. The default_packet_size parameter shall be set to 1024 octets to 
efficiently acccanodate the IP maximum packet size. 

3.2.8.2.3 CDNA Operational Parameters 

The Define_X25_Interface and Define_X25_Network ccanmands shall be used to 
specify the X25 CDNA operational parameters (refer to ARH6785, Network 
Definition, sees 9.5.4, 9.5.5.2). 

a. The cost parameter shall be set to 06FA(16) for a 56Kbps link, or to 
28B1(16) for a 9.6Kbps link. 

b. The relay_allowed parameter shall be set to NO. 

o o 
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c. "Hie routing_info_network parameter shall be set to NO. 

d. The ddn_x25_precedence, protocol_id, architecture_type, and pdn_name 
parameters shall be as defined in section 3.2.3.1. 

3.2.8.2.4 Configuration Example 

Following is a sample configuration excerpt for an X.25 connection to a PSN 
using DDN Standard X.25. 



O 



"-v. .y 



Define_X25_Trunk 
lim = 7 , , , 
port = 0, . . 

trunk_name = DDN_Interface, . . 
mode = DTE,.. 
max_unack_frames =7, 
pf_recovery_tiiner = 3000, 
retransmission_limit = 20, 
trunk_speed = 56000,.. 
clocking = EXTERNAL 



" Trunk for DDN Standard X.25 link ", 



" X.25 parameter K ".. 
" X.25 parameter Tl ".. 
" X.25 parameter N2 ".. 



vy 



Define_X25_Interface 

trunk_name = DDN_Interf£UJe, . . 

public_data_network = DDN_STANDARD, . . 

interface_name = DDN_Interface, , . 

local_dte_address = 100436(16), " DCA assigned 

packet_sequence_numbering = NCaS^AL, . . 

I?vc_range = 1..5, " DCA assigned 

outonly_range = 4090.. 4095, " DCA assigned 

default_window_size = 7, 

def ault__packet_size = 1024 , . . 

start = YES 



" Packet Level for DDN X.25 link ".. 



" DCA assigned 



o 
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Define_X25_Net 

trunkjiame = DDN_Interf ace , . . 
remote_dte_address = 52A8C0(16), 
network_id = 150, 
network_naine = DDN_Interface, . . 
cost = 06FA(16), 
relay_allowed = NO, 
routing_info_network = NO, 
network_protocol_id = CC(16), 
acceptjpdn_charges = NO, . . 
architecttire_type = dod, 
ddbi_x25_precedence = 0, . . 
start = YES 



" Network Solution for DDN X.25 

" DCA assigned " . . 
" CDCNET network id ".. 

" eissumes 56Kbps " . . 

" not a CDCa^ET net " . . 

" not a CEOnIET net " . . 

" DDN Stanciard pid " . . 

" not a CDCNET net " . . 



•^ 



o 



3.2.8.2 X.25 ^k)difications Transmittal 

3.2.8.2.1 Transmittal Files 

The following files are provided in the transmittal: 

a. X25 Modifications Program Library {X25nnnn) . This is an SES MODIFY 
formatted program library containing the X25 modifications. The FL 
uses a slash-prefix (SLASHPL) to maintain modsets to be applied 
against the CDCNET program library. 

3.2.8.2.2 Hi Structure 

The X25 modifications PL follows the PL conventions given in section 3.10.8. 
It contains the following decks in the indicated order: 



o 



o 



INSTALL Deck to contain sp)ecial installation procedure, empty for X25 

EDIT Deck containing EDIT directives required for X25 installation 

-MDDS- Empty deck marks beginning of modsets 

DDNX25 Deck containing front matter for DDN X25 feature modset 



© 
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^"\ HISTCSjy Deck containing modifications to CDCNET HISTORY deck (f\ 

One deck for each CDCNET PL deck that is modified. The deck ^"^ 

is named the same as the deck to be modified, and contains 
all modset lines for that deck. The decks appear in 
alphabetical order. 

ENDX25 Deck containing end matter for X25 modset 

-EbOM- Empty deck marks end of modsets 

-DECKS- Empty deck marks beginning of new decks, none supplied for X25 

-ENDD- Einpty deck marks end of new decks 

3.2.8.2.3 Dependencies 

No other DDN CPCI transmittals may depend ijpon the X25 transmittal. 

The X25 transmittal depends upon the CDCNET modifications transmittal (if 
any). 

/ > 3.3 Internet Protocol (IP) A 

v,.y . v.y' 

3.3.1 IP Abstract 

The IP protocol is designed to transmit and receive packets of information 
across the DDN and networks connected to the DDN. To conmunicate across 
multiple networks, IP supports a global addressing system and acccxnmodates 
differences in maximum packet sizes allowed by networks. IP has no 
nechanisms to promote data reliability, flow control, or sequencing. It 
provides only the basic functions necessary to deliver a block of data. 

3.3.2 IP Description 

The IP CPCI is specified in a separate document entitled DoD Internet 
Protocol ERS. That doctiment defines an IP design and implenentation that is 
based upon the Berkeley 4.2 UNIX IP. 
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3.3.3 External Interfaces 
Refer to the DoD Internet Protocol ERS, Section 3.0. 

3.3.4 Internal Interfaces 

Refer to the DoD Internet Protocol IDS, Section TBS. 

3.3.5 Errors and Error Recovery 

Refer to the DoD Internet Protocol ERS, subsection 3.5 

3.3.6 Data Structures 

Refer to the DoD Internet Protocol ERS, Section 8.0 

3.3.7 Equipment Configuraticm ' ^\ 

o 

DDN IP requires no special equipment configuration. 

3.3.8 Installaticxi 

Refer to the DoD Internet Protocol ERS, Section 7.0 

3.4 Transmission Control Protocol (TCP) 

3.4.1 TCP Abstract 

The TCP protocol is designed to provide reliable ccanraunication between pairs 
of processes in logically distinct hosts on networks and sets of 
interconnected networks. It provides connection-oriented data transfer that 
is reliable, ordered, full duplex, and flow controlled in an environment 
lAere loss, damage, duplication, or misordered data, and network congestion 

Ocan occur. ^ 
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3.4.2 TCP Description 



The TCP CPCI is specified in a separate document entitled DoD Transmission 
Ctontrol Protocol ms. That document defines a TCP design and implementation 
that is based upon the Berkeley 4.2 UNIX TCP. 

3.4.3 External Interfaces 

Refer to the DoD Transmission Control Protocol ERS, Section 3.0. 

3.4.4 Intemad Interfaces 

Refer to the DoD Transmission Control Protocol IDS, Section TBS. 

3.4.5 Errors and Error Recovery 

Refer to the DoD Transmission Control Protocol ERS, subsection 3.6. 

3.4.6 Data Stnx:tures 
Refer to the DoD Transmission Control Protocol ERS, Section 8.0. 

3.4.7 EquipiDent Configuratian 
DDN TCP requires no special equipment configuration. 

3.4.8 InstallatitHi 
Refer to the DoD Transmission Control Protocol ERS, Section 7.0. 



V__y ■ 'k^J 
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3.5 TELNET 

3.5.1 TELNET Abstract 

The TELNET protcxjol is designed to provide communication between hosts and 
terminals of different vendors. It is based upon the concept of a Network 
Virtual Terminal, the principle of negotiated options, and a symetric view of 
terminals and processes. During a session between a terminal and a host, 
TELNET resolves differences between the sictual characteristics of the 
terminal and those of NVT. 

3.5.2 TELNET Description 

The TELNET CPCI is specified in a separate document entitled DoD TELNET/BSD 
Gateway ERS. That document defines a TELNET and C3)NA/TELNET Gateway design 
and implementation that is based upon the Berkeley 4.2 UNIX TELNET, 

fj) 3.5.3 External Interfaces \J^ 

Refer to the DoD BSD Gateway/TELNET ERS. 

3.5.4 Internal Interfaces 

Refer to the DoD BSD Gateway/TELNET IDS. 

3.5.5 Errors and Error Recovery 
Refer to the DoD BSD Gateway/TELNET EfiS. 

3.5.6 Data Structures 

Refer to the DoD BSD Gateway/TELNET EEiS. 

O o 

(6443WAJP33) CCKTROL DATA PRIVATE 3-38 



v. 






KKSYSIM-OOS-ERS-OO-C 
10 December 1986 

3.5.7 Equipment Configuration (f I 
DDN TELNET requires no special equipnent configuration. 

3.5.8 Installaticm 

Refer to the DoD BSD Gateway/TELNET ERS. 
3.6 File Transfer Protocol (FTP) (RPC-765) 

3.6.1 FTP Abstract (RPC-765) 

The purpose of FTP is to provide xxsers of possibly dissimilar ccmputers the 
capability to exchange files of ccanputer programs and data without requiring 
knowledge of each computer's file storage system. 

The FTP will provide server and user functions for DDN users. The server 

function will provide ronote DDN users and applications with access to the L J 

CYBER host file systan. The user function will provide CYBER host tenninal 

users and DDN TELNET users with access to file systems on remote hosts. 

3.6.2 FTP Description (RPC-765, pg 248) 

Figure 3.6-1 illustrates a model of the FTP service in v4iich the user 
initiates a TELNET connection to the server. FTP ccramands and responses are 
sent and received via the TELNET connection while file transfers are 
accomplished via the data connection. 

At the initiation of the user, standard FTP commands are generated by the 
User-Protocol Interpreter (PI) and transmitted to the server process via the 
TELNET connection. The user may also establish a direct TELNET connection to 
the Server-FTP, from a TAG terminal, for example, and generate FTP cannands 
himself, bypassing the User-FTP process. Replies are sent frcan the 
Server-Protocol Interpreter (PI) over the TELNET connection in response to 
a ^ the commands. 
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The FTP ccanmands specify the i)arajneters for the data connection (data port, 
transfer mode, representation type, and structure) and the nature of file 
system operation (store, retrieve, append, delete, etc.). The User-Data 
Transfer Process (DTP) will "listen" on the specified data port, and the 
Server-Data Transfer Process (DTP) will initiate the data connection and data 
transfer in accordance with the specified parameters. 

It shoiild be noted that the data port need not be in the same host that 
initiates the FTP commands via the TELNET connection, but the tiser or his 
User-FTP process must ensure a "listen" on the specified data port. It 
should also be noted that the data connection may be used for both sending 
and receiving and that FTP must support transfer of files between two hosts, 
neither of vdiich is the user's host, the latter case is illustrated in 
Figure 3.6-2 where TELNET connections are established between two server 
FTPs. In this figure, control information is passed to the User-PI but data 
is transferred between the two Server-DTPs. 

|[^ The CYBER FTP implementation consists of four components: the FTP Ctontrol \J^ 
Statement, the FTP Application Interface routines, the FTP Protocol 
Interpreter (PI), and the FTP File Server. Figure 3.6-3 depicts the FTP 
components and their interfaces. The FTP protocol interpreter implements 
both User and Server PI functions. A single FTP PI exists in a CYBER, so 
many user and server connections must be multiplexed. The command-response 
interface to FTP PI can be from TCP connections for access by remote FTP 
processes or frcm NAM A-A connections for access by TEI2QET lisers and local 
application programs. The FTP Application Interface (AI) routines provide 
the NAM A-A interface for application programs. Actual data transfer and 
file handling is performed by FTP File Servers (FS). 

The FTP Control Statement (CS) ccmponent uses the FTP AI routines to provide 
a job-level (batch or interactive) interface to FTP. 



o o 
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\ ■■] The various FTP components communicate via NAM connections that EU7e depicted \^ 
in Figure 3.6-3 and summarized below: 

1) FTP Application I/F to Protocol Interpreter. This connection is 
initiated by the AI and terminated by the PI. One connection exists 
for eeuih instance of the Application I/F, which can be resident 
either with an FTP CkDntrol Statement or with a user application. 
Many instances of both the control statement and \xser applications 
are possible. 

2) FTP File Server to Protocol Interpreter. This connection is 
initiated and terminated by the PI. One connection exists for each 
instance of the File Server. 

3) FTP TCP Data Connection to remote FTP. This connection can be 
initiated and terminated by either the local FTP File Server or by a 
rsnote FTP, at the request of the PI. The NAM connection is created 

m\ indirectly via the TCP/IP C170 DoD Interface routines and is between \^ 

the File Server and the NP DoD Gateway residing in the MDI. One 
connection exists for each FTP file server that heis a TCP data 
connection with a remote FTP. 

4) FTP TEINET Command Connection to ronote FTP. This connection can be 
initiated and terminated by either the local FTP Protocol 
Interpreter or by a remote FTP, at the request of the PI. The NAM 
corjnection is created indirectly via the TCP/IP C170 DoD Interface 
routines and is between the Protocol Interpreter and the NP DoD 
Gateway residing in the MDI. One connection exists for each TELNET 
connection between FTP PI and a remote FTP. 

5) FTP to DDN Supervisor. This connection is initiated and terminated 
by FTP PI and FTP File Server. The NAM connection is created 
indirectly via the Supervisor C170 DoD Interface routines for the 
name server and error logging services. One connection exists for 

■ ^ the PI and for each instance of a File Server. ^J 
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yj 3.6.2.1 File Transfer Functions {RFC-765, pg 263) (J) 

File transfer functions shall be initiated by the user sending FTP commands 
to the server and interpreting the returned replies, and the server shall be 
resfwnsible for interpreting and processing commands and sending replies and 
data to the user. 

3.6.2.1.1 FTP Command Syntax (RFC-765, pg 284) 

The FTP commands are TELNET ASCII character strings terminated by the TELNET 
end-of-line code and are partitioned as those specifying access-control 
identifiers, data transfer parameters, or FTP service requests. The syntax 
of all FTP commands shall be as specified in a. through f . below. 

a. FTP consnands shall begin with a ccanmand code of from one to four 
alphabetic ASCII characters. (RFC-765, pg 284) 

\^ b. Upper and lower case aljAiabetic characters shall be recognized \J^ 

equally in the coiranand code. (RFC-765, pg 284) 

c. An argument field, if present, shall follow the ccHimand code and 
shall be separated from the ccanmand code by one or more ASCII 
spaces. (RFC-765, pg 284) 

d. The argument field shall consist of a variable length ASCII 
character string. (RFC-765, pg 284) 

e. Upper and lower case alphabetic chsu^acters shall be recognized 
eqiaally in the argument field. (RFC-765, pg 284) 

f . The FTP ccanmand shall be terminated with the TELhJET erai-of-line code 
consisting of the ASCII cheur^cter sequence of Carriage Return and 
Line Feed. (RFC-765, pg 284) 

O O 
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\J)l g. No action shall be taken by the FTP server until the TELNET X^Jf 

end-of-line code is received. (RPC-765, pg 284) 

^K)TE: The actual command codes, argument fields, and syntax of all 
FTP commands to be implemented are stated in subsections 
3.6.2.1.1.1 through 3.6.2.1.1.3 below. 

3.6.2.1.1.1 Access Control Ckammands (RFC-765, pg 263) 

Access Control Commands define users' axxsess privileges to the use of a 
syst«n and to the files in that system. They are used to prevent 
unauthorized and accidental use of a system and files and are enforced by the 
server FTP. These commands are described below. 

NOTE: In the COMMAND PCS^MAT subsections a.l through e.l, it&os enclosed in 
brackets [] have the following meaning: 

X y [SP] - represents one ASCII space. v^^ y 

[ . . . 1 - represents a command argument. 

[CfiLF] - represents the TELNET end-of-line character string of 
Carriage Return Line Feed. 

a. USER NAME COMMAND (RFC-765, pg 264) 

The user name ccanmand shall be a TELNET string that identifies the 
user to the server FTP for access to the NOS file system. 

1. COMMAND PCMIAT - USER [SP3[ FAMILY ] [,USERNAME][,PASSWCM)] 
(RFC-765, pg 285) 

USER - The ccanmand code shall be the character string "USER" 
upper and/or lower case ASCII chauracters. 



■\ 
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f^ FAMILY - The FAMILY argument is optional. If present, it shall f^ 

consist of one to seven alphanumeric characters. If omitted, 
the default family is used. 

USERNAME - The USERNAME argument shall be a NOS user number that 
shall consist of one to seven alphanumeric characters. Note 
that ^Aether or not the FAMILY argument is present, USERNAME 
shall be preceeded by a comraa( , ) . 

PASSWORD - The PASSWORD argument is optional. If present, it 
shall be a MDS password that shall consist of one to seven 
alphanumeric characters and shall be preceeded by a ccHnma( , ) . 

If password is omitted, a 331 response is issued with the text 'need password 
for login' and the user must enter the PASS ccanmand. If peissword is 
supplied, a 230 or 332 response is issued. Use of the PASS command instead 
of direct entry on the USER command may provide more secure entry, since the 
£^ user FTP may sxjpply overprint, no-echo, or other protection. CYBER user C^ 

interactive FTP will provide overstrike characters, similar to the NOS 
pEissword command, but will not attaiqpt to change echo (since most CYBBR 
systems use local terminal echo). Thus, the protection offered by a CYBER is 
only useful for hard-copy terminals; it is suggested that a CSfT user enter 
the terminal's screen-clear character following the peissword if protection is 
needed. 

The USER ccanmand can usually be entered at any time, but doing so will 
require re-entry of the PASS and ACCT ccanmands. However, if the site has 
disabled secondary user ccanmands, the USER ccanmand can only be entered once. 

If the family/usemame /password combination is incorrect, a 530 response is 
returned. Entry of any command other than USER/PASS/ACCT/HELP/REIN/QUIT/ 
ABOR/ NOOP will result in a 532 response. If a correct combination is 
entered but the security count is exhausted, a 431 multi-line response is 
sent with a 'security count exhausted* message and FTP closes the TELNET 
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\|^J) connection; if the command was sent from a local user, the NAM connection I I 
with that user is also terminated. 

b. PASSWORD 0»1MA>3D (RFC-765, pg 264) 

The Password command shall be a TELNET string identifying the user's 
p»assword to the server FTP for access to the NCS file system. 

1. CXM^ND FCMikT - PASS[SP] [PASSWCM)] [CRLF] 

PASS - The command code shall be the character string "PASS" in 
\q>per and/or lower case ASCII characters. 

PASSWORD - The PASSVKM) argument shall be a NCS password that 
shall consist of one to seven alphanumeric characters. 



The password is always required on a NOS system. If not supplied with a USER 
coiranand, then it must be supplied with the PASS command. If the peissword was 
supplied on the USER ccmHnand, a 202 response with the text 'comnand 
superfluous, password already given' is issued. The PASS command can be 
entered only immediately after a USER command; if it is entered at any other 
time, a 503 response is returned. 

A tiser or peer FTP has only three (installation changeable) chances to enter 
a correct family /user/password ccanbination v*ien first logging into FTP. 
After the third failure, a 431 multi-line response is sent with a 'user retry 
limit exceeded' message and FTP closes the TELNET connection; if the ccMiimand 
was sent frcMn a local user, the NAM connection with that user is also 
terminated. The retry limit does not apply to subsequent (that is, 
secondary) USER commands issued in the same FTP session; these commands are 
subject only to the user's security count £us described above. The site can 
disable the retry limit (that is, define an unlimited retry) by setting the 
installation parameter to zero . 
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_J Note that if the user has different batch and interactive passwords, the 

BATCH peissword must be entered. 

c. ACCOUNT COMMAND (RFC-765, pg 264) 

This command shall be used to identify the laser's account and to 
record on the NOS account dayf ile information regarding resources 
used. 



1. COMMAND Fra^lAT - ACCTISP][CHARGENUM,EROJECTNlM][CRLF] 

-or- 

ACCT[SP][*1 
^^ (RFC-765, pg 285) ^^^ 

o o 

ACCT - The ccanmand code shall be the character string "ACCT" in 
upper and/or lower case ASCII characters. 

CHAI^aNUM - The CHARGENUM argument shall be a NOS charge number 
assigned by the sit to the user and shall consist of 1 to 10 
alphanumeric chsiracters in upper suid/or lower CEuse. The comma 
following CHARGEMJM shall be mandatory. 

FROJECR'JUM - The FROJECTNUM argument shall be a NCS project 
number assigned by the site to the user and shall consist of 1 
to 20 alpiianumeric characters in upper and/or lower case. 

* - If the ACCT conmand is entered with the * parameter, the 
default cheurge is used ( if one is defined and it is valid) . 
Note that the ACCT * command is redundant since the default 
charge is always assumed if one exists; it is provided for ^-^ 
\J> consistency with existing NOS coranand format. '\jl 
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S^J) A typical NCS site will require an ACCT conimand. An ACCT command will not be (f^ 
required in the following instances: 

1) The user has the charge-not-required (CCNR) bit set in his 
validation file entry (AACW) . 

2) The user has a default charge/project defined in his validation file 
entry. In this case, the default charge/project (if valid) are 
autcHnatically used unless an ACCT command is given. 

If a charge is not required, a 230 response is returned from the USER 
command. If a charge is not required and an erroneous ACCT comnand is issued 
(that is, invalid charge) then a 202 response is issued with the text 
'command superflous, charge rejected' followed by an extended eriror message 
containing the NOS CHAROE processor diagnostic (see diagnostics, VDS v. 3). 



v.y 



.y 



If the charge-not-restricted- to-default (CNRD) bit is set in the users 
validation file entry (AACW) then any charge for vdiich the user is validated 
can be entered. Otherwise, only the defaiiLt charge is permitted. 

Although a charge can be entered at any time on a NOS system, the FTP 
error/response system only permits entry of an ACCT conanand after a USER/PASS 
command sequence. Entry of ACCT any time except after a USER/PASS sequence 
will result in a 503 response. 

Charged Resource Usage . Only resources used by the file server are charged 
to the specified account. This means that only actual file transfer resource 
usage is charged; resources used by the protocol interpreter to process 
ccaranands, give help, etc, are charged to an overhead account determined by 
the site. When the user terminates the FTP connection, all file seirver 
resources \jised vdiile idle (idiich are small) sire also charged to an overhead 
account. Note that any resources used by contrtjl statement processing (FTP 
control statement) are charged to the account under viiich the user is 
currently running; this account is changed only by the NOS USER and CHARGBE 
jf ^ statements, and is not affected by the FTP USER/ACCT commands. 1^ 
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After a successful vser command has been entered, the permanent file 
restrictions associated with that account apply to the FTP file server. For 
example, if the user is not validated to create direct access files (CLPF in 
AACW validation entry) then FTP will not be able to do so either and an error 
will result if the user requests FTP to create a direct access file. The 
validations covered by this include CLPF, CSPF, CSRP, CSAF, CLTD, CS, DS, FC, 
FS, MS, RP, SAL, CFPX, CLFL, CKLF. The validation mnemonics are defined in 
the NOS Administration Handbook. 

Extended USER/ACCT Responses . Several error responses are possible from an 
ACCT command, depending on the reason for charge failure (see diagnostics, 
NOS v,3). If the charge fails for reasons other than syntax errors, a 
multi-line 530 response will be issued with the text 'Not logged in, account 
rejected' followed by a line containing the specific diagnostic frc«n the NOS 
charge processor (for example, 'invalid cdiarge', 'charge expired'). A 
HBilti-line 431 response can be issued for certain user ctsnmand failvires also 
with the subsequent line consisting of the specific NOS user processor 
\J diagnostic. ■ \J) 

Da>^ile and Account Messages . Whenever file server changes \iser or cheurge 
ntimbers, the appropriate messsiges are issued to the dayfile and account file, 
in 8«3cordance with NCS accounting convaitions. When the first successftil 
user command is entered for a user, an ABUN is issued to the account dayfile; 
if a default chaurge is associated with the new user name, an ABIC message is 
issued to the eiccount dayfile. An ACUN message is issued for subsequent 
successful user commands from the same user. Several account messages are 
also issued by modules called from FTP (for example, C£fi and OCMCCHG) and are 
not documented here. 

Remote vs. Local Users . A remote user of a CYBER FTP system must always send 
a USER/PASS/ACCT sequence to FTP. A local user (that is, a user logged into 
the NCS system where the FTP is executing) need not enter a USER/PASS/ACCT 
sequence to the local FTP. If no sequence is entered, the user and charge 
account under which the user is currently operating are assumed; this 
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(f 1^ user/charge is specified using NOS USER and OIARGE control statements. If a (O) 
local user does enter FTP VSER/ACCT commands, only the file server operation 
is affected; the user's job (and FTP control statement execution) continues 
under the account specified in the NOS USER/C3IARGE control statements. A 
USER/PASS sequence entered by a local user is treated as a secondary user 
ccMranand: secondary user commands must be enabled, the user retry limit does 
not apply, and the primary user security count is decremented for each 
invalid secondary usemame/password. Note that a local CYBER user must still 
supply USER/PASS/ACCT commands to the remote server FTP (or both servers, if 
third-psirty transfer is used). 

d. REINITIALIZE COMMAND (RPC-765, pg 265) 

Ihis conmiand shall caxise the server FTP to con5>lete any file 
transfer in progress, flush all I/O and account information, and 
terminate the effects of the Isist USER ccMnmand. 



'■-^y 



1. CCMMAND FCSJMAT - REIN[CRLF] (RFC-765, pg 285) 

REIN - The comnand code shall be the character string "REIN" in 
upper and/or lower case ASCII characters. 

COWAND EXAMPLE - REIN 

2. The server FTP shall reset defaults and leave the TELNET 
connection open after terminating the user. (RFC-765, pg 265) 

3. The server shall then require a USER command before additional 
FTP functions may be performed. (RFC-765, pg 265) 



V,„j^ 
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e. LOGOUT OCWMAND (RFC-765, pg 265) |_y' 

This coiimand shall cause FTP to complete any file transfer in 
progress, terminate the user, and close the TELNET connection. 

1. OCMMA^JD PC»MAT - QUITICRLF] <RFC-765, pg 285) 

QUIT - The command code shall be the character string "©JIT" in 
tr^jer and/or lower case ASCII characters. 

COMMAND EXAMPLE - QUIT 

3.6.2.1.1.2 Transfer Piarameter Commands (RPC-765, pg 265) 

ITie transfer parameter commands shall be used to change default parameter 
values from the Isist value specified by a transfer peui-ameter canmand or, if 
none specified, from the standard defatilt values stated below. There shall 
^^ be no order dependency associated with transfer parameter ccanmands except \J) 
that they must all precede the FTP service commands. 

NOTE: In the CCMIAND PCMIAT subsections a.l through e.l, items enclosed in 
brackets [] have the following meaning: 

[SP] - represents one ASCII space. 

[...] - represents a command argument. 

[CRLF] - represents the TELNET end-of-line character string of 
Carriage Return Line Feed. 

a. DATA PC5?r COMMAND {RFC-765, pg 265) 

The data port command shall be used to specify the data port for use 
in the data connection. 

o o 
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/ 1^ 1. OCMrlAND FORMAT - PORT[SP] [HCfiT-PORT] [CRLF] (RFC-765, pg 285) 

PORT - The command code shall be the character string "PC«T" in 
upper and/or lower case ASCII characters. 

HOST-PORT - The HOST-PCKT eurguraent shall consist of a 32-bit 
internet host address and a 16-bit TCT port address divided into 
8-bit fields separated by cOTonas. The value of each 8-bit field 
shall be a decimal number in the range of to 255 represented 
as an ASCII numeric chauracter. (RFX:!-765, pg 266,285) 

OCMMAND EXAMPLE - PORT hl,h2,h3,h4,pl,p2 tAere hi is the high 
order 8 bits of the internet host address and pi is the high 
order bits of the TCT port eiddress. 

2. A FTP user shall listen on a port specified in a PCKT OOIMAND. 
{RFC-765, pg 282) 

"^"^^ 3. A FTP server shall initiate the data connection from his default 

data port using the port specified in a PORT CCMIAND. (RPC-765, 
pg 282) 

4. the user FTP default data port shall be port U. (RPC-765, 
pg 257) 

5. The server FTP defaiilt data port shall be port L-1. (RFC-765, 
pg 257) 

b. PASSIVE OC^IMAND (RFC-765, pg 266) 

The passive command shall cause the seiTver FTP to listen on a data 
port (not the default data port) and wait for a connection rather 
than initiate a connection upon receipt of a transfer service 
commEind. 

\J ■ ' \^ 
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^-^ 1. CXWMAND FORMAT - PASV[CRLF] (RFC-765, pg 285) gr^ 

PASV - The command code shall be the character string "PASV" in 
upper and/or lower case ASCII characters. 

CCWMAhJD EXAMPLE - PASV 

2. The server FTP shall provide a reply code of 227 with an 
internet host address and a TCP port address in the format shown 
in subsection 3. 6. 2. 1.1. 2. al above for the TCMT command. 
(RFC-765, pg 266) 

c. REPRESENTATION TYPE CCWMAh© (RFC-765, ^ 266) 

1. a»flAha) PCMIAT - TYPE[SP][TYEE CODE 1][CRLF3 

- TYPE[SP] [TYPE CODE 2][CRLF] (RFC-765, pg 285) 

- TYPE[SP][TYPE CODE 3] [CRLFJ 

^^' TYPE - The conanand code shall be the character string "TYPE" in ^^ 

upper and/or lower case ASCII characters. 

2. TYPE CODE 1 - The TYPE OC»E 1 argument shall specify the data 
type for the file transfer as ASCII with a second argument that 
specifies that the file contains no vertical format information, 
the file contains TELNET vertical format control characters, or 
the file contains FORTRAN vertical format control chairsictei^ . 
The TYPE CODE 1 arg\jment shall be recognized in upper and/or 
lower ceise as shown below. (RFC-765, pg 266) 

AtSP]tN or T or C where 

3. A - This is the ASCII character "A" that specifies ASCII file 
transfer. (RFC-765, pg 266) 

o o 
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4. N - This is the ASCII character "N" that specifies that the file (f\ 
contains no vertical format control information. Ihis is the 

default. (RFC-765, pg 266) 

5. T - This is the ASCII character "T" that specifies that contains 
TELNET vertical format control characters. (RFC-765, pg 266) 

6. C - This is the ASCII CHARACTER "C" that specifies that the file 
contains PORTEiAN vertical format control characters. {RFC-765, 
pg 266) 

0»MWD EXAMPLE - TYPE A T ASCII with TEUsET format control 

- TYPE A C ASCII with FORTRAN format control 

- TYPE A N ASCII with no format control 

7. TYPE CODE 2 - The TYPE CODE 2 argument shall specify the data 
type for transfer as Image with data sent as contiguous bits . 

The TYPE CODE 2 argument shall be recognized in upper and/or ^ ^ 
lower case in the format shown below. (RFC-765, pg 253, 266) 



CaiMAND EXAMPLE - TYPE I 

8. TYPE CODE 3 - The TYPE CODE 3 argument shall specify the local 
byte size option. This type code is intended to facilitate file 
transfers between two Cyber hosts. Reference section 3.6.2.5.7 
for details of this option. The TYPE CODE 3 argument shall be 
recognized in upper and/or lower caise in the format shown 
below. (RPC-765, pg 253, 266) 

L[SP]60 

OCMIAND EXAMPLE - TYPE L 60 

o c 
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Cv d. FILE STF2UCTURE OCWMAh© (RFC-765, pg 267) f^ 

The file structure ccanmand shall specify the file structure for file 
transfer. 

1. CXM^^a) FORMAT - STRU[SP]S-C»DE[CRLF] (RFC-765, pg 285) 

STRU - The connnand code shall be the character string "STRU" in 
upper and/or lower ceuse ASCII characters. 

S-OODE - The S-OODE argument sheill be one of the following 
single ASCII characters in upper or lower case. (RFX>-765, 
pg 267) 

F - File structure (no record structure) 

R - Record Structure 

COIMAND EXAMPIE - STRU F ^^ 

- STRU R 

2. The defaiilt file structure shall be File. (RFC-765, pg 267) 

NOTE: See 3.6.6.2a and b for definition of File and Record 
structures. 

e. TRANSFER MODE COMMAND (RFC-765, pg 267) 

The transfer mode ccHnmand shall specify the mode for file transfer. 

1. COMMAND PC5MAT - M0DE[SPlM-00DE[byte-si2e] [CRLF] (RPC-765, 
pg 285) 

MODE - The ccxnmand code shall be the chsiratcter string "MODE" in 
jP(| upper and/or lower case ASCII characters. jm^ 
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M-OODE - The M-OODE argument shall one of the following single 
ASCII characters in upper or lower CEise. {RFC-765, pg 267) 

S - Stream 

B - Block 

C - Compressed 

L - Local Byte 

byte-size - The number of bits associated with M-CDDE = 'L' 

CXMIAND EXAMHuE - MODE S 

- MODE B 

- MODE C 

- MODE L60 

2. The default transfer mode shall be Stream. {RFX>765, pg 267) 

hKDTE: See 3.6.6.2a, b, and c for definition of Stream, Block, 
and Compressed modes. 

f. SITE OO^MAIffi (RFC-765, pg 272) 

The SITE ccxnmand allows an FTP user to specify typical NOS defaults (for 
example, alternate packnam, cheiracter set) so that they do not have to 
be entered for each ccsnmand. It also allows a CYBER- to-CYBER transfer 
to be specified so that NOS-specific information is not lost. The 
format of the SITE ccsnmand is: 

SITE[SP]NOStSP]pl,p2,p3,...,pn[CRLF] (RPC-765, pg 285) 



~^_.> 



o 
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vihere ixi are order-independent parameters. The NOS keyword is 
required. If it is canitted, FTP will reject the SITE ccaranand. The 
following parameters are defined: 



■^ 



o 







Affected 


Parameter 


Description 


Fl'P Command(s) 


FN=packnaune 


Pack name 


all, incl. LIST 


R=r 


Device type 


all 


UN=usemame 


User name 


all, incl. LIST 


Kr=rt 


CKM record type 


all 


MEtti=iiirl 


CKM maximum record length 


all 


EL=fl 


CKM fixed length 


all 


DA 


Direct success 


all 


lA 


Indirect access 


all 


TO 


Local access 


all (local Fi'P 


PF 


Permanent access 


only) 
all 


RhADEOI 


Read-to-EOI flag 


RbTK only 


CS=cs 


Character set 


all 


TRUNC 


Pad processing 


STCH/APPE 


PKEK 


CYBER-to-CYBER defaults 


STCR/RETR/APPK 



o 



ftice a parameter is specified in the SITE ccannand, any subsequent 
ccmmand to vdiidi that parameter might apply will use the value of the 
parameter unless a different value is specifically given. A subsequent 
SITE command can change the defaults again, or a re-initialize (REIN) 
command will clesur the effects of all SITE canmand parameters. Only 
parameters specified in the command are changed; other parameters retain 
their current default values. 



O 
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■ff"'\ "J^e PEEK parameter is a special parameter that informs FTP that its peer 

^' is another CYBER. This causes the following things to happen: 

1) The representation type is changed to TYPE L 60 (local byte 60) 

2) The file structure is dianged to STRU R (record structure) 

3) Subsequent transfers will interpret the FTP record/file mark 
codes differently so that NOS EOF marks will be retained through 
the transfer. 

4) The READEOI flag is cleared if previously set. 

Since the FTP codes are interpreted differently, it is important not to 

send a SITE NOS PEER command to a CYBER FTP if the other FTP is not a 

CYBER FTP. Doing so will result in a protocol error declared by one or 
the other FTP. 



„y 



A local CYBER FTP user can send the SITE NOS PEER ccarmand to either the 
local or remote FTP. If sent to the ronote FTP, the local FTP will see 
it aiKi if a successful response is received from the remote FTP then the 
local FTP will change its status also. If sent to the local FTP, the 
local FTP will automatically send one to the remote FTP and if a 
siKxsessful response is received frcan the remote FTP then the local FTP 
will change its status and return a success response to the user. If 
the remote FTP retvums an unsuccessfvil response, the local FTP will not 
change its stattis. It is therefore not possible for a local CYBER user 
to send a SITE NOS PEER command to a non-CYBER FTP, since presumably the 
non-CYBER FTP would reject the SITE ccmimand. However, a local non-CYBER 
FTP user could presumably send a SITE NCS PEER command to a remote CYBER 
FTP, causing the problem discussed earlier. 
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\J) 3.6.2.1.1.3 FTP Service CkMimands (RFC-765, pg 267) xj 

The PTP service comraands shall define the file transfer or the file system 
function requested by the user. The only order dependency allowed for FTP 
SERVICE COMMANDS shall be that REN.AME FRC^ shall be followed by RENAME TO and 
that RESTAEJT shall be followed with the interrupted PTP service cointnand, such 
as RETRIEVE or STORE. 

NOTE: In the OCX-IMAND FGESMAT subsections a.l through j.l, items enclosed in 
brackets [] have the following meaning: 

[SP] - represents one ASCII space. 

[...] - represents a command argument. 

[CRLF] - represents the TELNET end-of-line cheiracter string of 
Carriage Return Line Feed. 

gm. »• RETRIEVE CCMMAND (RPC-765, pg 268} g^ 

This command shall cause FTP to transfer a copy of the named file to 
a server or user FTP at the other end of the of the data connection. 

1. COMMAND FORMAT - RETR[SP] [PATHNAME] [CRLF] (RFC-765, pg 285) 

RETR - The ccmmand code shall be the character string "RETR" in 
iQjper and/or lower case ASCII characters. 

PATHNAME - The PA'niNAME argument shall be as defined in section 
3.6.2.5.1. 

EXAMPLE - RETR FILE1,PN=ALTPACK,PW=RASSWRD 

2 . Ihe status and contents of the file at the server FTP shall be 
unaffected by execution of the RETRIEVE COMMAND. (RFC-765, 
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O b. STOBE COMMAND (RFC-765, pg 268) O 

This command shall cause FTP to accept the data from the data 
connection and to store the data as a NOS file. 

1. CaiMA>a) FORMAT - STCXiLSP] [PATHNAME] [CRLF] (RFC-765, pg 285) 

STOR - The command code shall be the character string "STOR" in 
upper and/or lower case ASCII cheuracters. 

PATHNAME - The PATHNAME argument shall be as defined in section 
3.6.2.5.1. 

EXAMPLE - STOR FILE1,R=DQ,CT=FU,M=R 

2. The server FTP shall create a file if the named file does not 
exist at the server site and shall replace the file with tJlie new 

V y data if the named file does exist. The default file type shall V y 

be direct access. The SITE command shall be used to change the 
default file type to indirect access. {RFX>765, pg 268) 

c. APPEND CCMMAND (RFC-765, pg 268) 

This command shall cause the server FTP to accept the data frcan the 
data connection and add it to the end of an existing file with the 
same name or create a new file to contain the data. 

1. COMMAND FORMAT - APPE[SP] [PATHNAME] [CRLF] (RFC-765, pg 285) 

APPE - The command code shall be the character string "APPE" in 
upper and/or lower case ASCII characters. 
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C^ PATHNAME - The PATHNAME argument shall be as defined in section /^ 

3.6.2.5.1« .^. 

EXAMPLE - APPE FILEl 

d. RESTART COMMAND (RFC-765, pg 270) 

The server FTP shall position the file to the marker and shall 
resume the file transfer only upon receipt of the appropriate 
service command frcan the user FTP. (RFC-765, pg 270) 

1. C»]MA^3D FCMIAT - REST[SP] [MARKER] [CRLF] {RFC-765, pg 285) 

REST - The command code shall be the character string "REST" in 
tapper and/or lower catse ASCII chaj^cters. 

2. MARKER - The argument field shall represent the server FTP 

#*%! marker at which the server FTP shedl restart the file transfer. #>j 

(RFC-765, pg 270) 

3. Ihe marker shall consist of a string of ASCII printable 
character codes of 33 through 126 decimal contained in a block 
header code of a file transferred in BLOCK or CGMFRESSED mode. 
(RFC-765, pg 261,285,286.) Section 3.6.2.4.4 defines the NOS 
marker format. 

EXAMPLE - REST mrkrid 

e. RENAME FRCM COMMAND (RFC-765, pg 270) 

This command shall specify the file to be renamed by the server FTP 
upon receipt of the RENAME TO canmand. Note: It is the 
responsibility of the user to issue the RENAME TO conmand. 

o o 
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■f'\ 1. COMMAND FORMAT - RNER[SP] [PATHNAME] [C3iLF] (RFC-765, pg 285) 

RNER - The command ccxie shall be the character string "liNFR" in 
upper and/or lower case ASCII characters. 

PATHNAME - The PATHNAME argument shall be as defined in section 
3.6.2«5.1. 

EXAMPLE - RNFR FILE1,PW=PASSWRD 

f. RENAME TO COMMAND (RPC-765, pg 270) 

This command shall specify the new file name for the file named in 
the immediately preceeding RENAME FRCM command. 

1. COMMAND FORMAT - RNT0[SP3 [PATHNAME] [CRLF] (RFC-765, pg 285) 

^ RNTO - The ccanmand code shall be the character string "RNTO" in ' 

upper and/or lower case ASCII characters. *^ 

PATHNAME - The PATHNAME argument shall be as defined in section 
3.6.2.5.1. 

EXAMPLE - RNTO FILEl 

g. DELETE C(»1MAND (RFC-795, pg 271) 

This ccMnmand shall cause the server FTP to delete the named file at 
the sers'er site. A cautioneiry message shall be provided by user FTP 
to NOS interactive terminal users prior to file deletion. 
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\3 1- OM^ND FORMAT - DE1JE[SP] [PATHNAME] [CE?LF] (RFC-765, pg 285) V.) 

DELE - The command code shall be the character string "DELE" in 
upper and/or lower case ASCII charaursters. 

PATHNAME - The PATHNAME argument shall be as defined in section 
3»6«2«5« 1» 

EXAMPLE - DELE FILEl 

h. LIST OCmMD (RFiC-765, pg 271) 

This command shall cause the server FTP to send a list of files to 
the user FTP. 

1. COMMAND FORMAT - LIST[SP] [USERNUM] [CRLF] (RFC-765, pg 285) 

\J LIST - The command code shall be the character string "LIST" in xJ 

iipper and/or lower case ASCII chareicteirs. 

USERNLM - The USERN1JM argument shall be a NOS liser number that 
shall consist of one to seven alphanucBeric characters. 

It shall be an optional argument and, if used, shall specify an 
alternate NOS user catalog for vdiich a list of files shall be 
produced. 

If the argument is not specified a list of files in the current 
catalog of the user shall be produced. 

EXAMPLES - LIST 

- LIST DDNUSER 



O O 
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NOOP - The command code shall be the character string "!«X)P" in 
upper and/or lower case ASCII characters. 



o 



i. 0(»1MAND POI^IAT - HELP[SP][KEY WORD][CKLF] (RFC-821, p29) 

HELP - the command code shall be the character string "HELP" in 
upper and/or lovrer case ASCII characters. (RFC-821, pp25,27) 

KEY WCM) - The KEY WORD argument shall be an ASCII upper and/or 
lower case character string that indicates the type of help wanted. 

EXAMPLE - HELP SITE 

The topics to be supplied include a general help discussion (no 
topic name), a topic called TOPICS v4iich list all possible help 
topics, PARAMETERS which lists all possible parameters, REMOTEUSER 
vdiich provides remote user-specific info, LOCALUSER vdiich provides 
local user-specific info, ERRCaS which provides general error help, 
a set of Exxxx topics for specific errors vdiere xxxx is a specific 
X error code (the text will discuss jxDssible corrections, not just / , 

V reiterate the original error message text), EXAMPLE vdiich gives an v..^ 

exan^le of a file/mail transfer, and MINIMAL which describes the 
minimal set of commands and parameters to do a rudimenteury file/mail 
transfer. There will also be at least one topic for each command 
and each parameter, plus topics on general subjects such as record 
structures, character sets, examples, etc. 

j. NOOP OCmAND (RFC-765, pg 273) 

This command shall specify that no action be taken by the server FTP 
except to send an (M reply. 

1. COMMAND FORMAT - NOOP[CRLF] (RFC-765, pg 285) 






EXAMPLE - NOOP \J 
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\y k. ABORT COMMAND (RFC-765, pg 270) Vy* 

This command shall cause FTP to abort the previous FTP service 
ccmimand and any associated ongoing transfer of data. 

1. COMMAND FORMAT - ABQRLCRLF] (RPC-765, pg 285) 

ABCR - The command shall be the character string "ABOR" in upper 
and/or lower case ASCII characters. 

EXAMPLE - ABOR 

3.6.2.2 FTP Replies (RPC-765, pg 274) 

Replies to FTP commands shall be used to ensure synchronization of requests 
and actions during the process of file transfer, and to guarantee that the 
^,^^ user process always knows the state of the server. ^i,^ 

o o 

NOTE: In the following paragraphs [SP] means an ASCII space and [CRLF] meams 
a TELNET end of line (ASCII Carriage Return followed by an ASCII Line 
feed) . 

a. At leaust one reply shall be generated by the FTP server for every 
FTP command received. (RFC-765, pg,274) 

b. A single line FTP reply shall consist of a 3-digit code transmitted 
as three alphanumeric characters followed by a ISP], followed by one 
line of text, followed by a [CRLF]. (RFC-765, pg,274) 

c. Multi line replies shall consist of a 3-digit code, followed 
immediately by a Hyjiien "-" (also known as a minus sign), followed 
by text. The last line shall begin with the ssms 3-digit code, 
followed by a [SP] , scane optional text, and terminated by a [CRLF] . 
(RFC-765, pg 275) ■^ 

O O 
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O 3.6.2.2.1 FTP Reply Ckxies (RFC-765, pg 276) . \J 

The reply codes and their meaning shall be as shown below: 

a. The first digit, most significant, of the reply code shall have one 
of the following values: (RFC-765, pg 276) 

1. Ixx - Positive preliminary reply (RPC-765, pg 276) 

The requested action is being initiated; expect another reply 
before proceeding with a new command. The server FTP shall 
queue additional commands received while the preceding command 
is in progress. 

2. 2xx - Positive ccanpletion reply (RPC-765, pg 276) 



The requested action has been SLiccessfully completed and the 



,/^" 



V_y user FTP may initiate a new request. V y 

3. 3xx - Positive intermediate reply (RFC-765, pg 276) 

The command has been accepted. Action is held in abeyance 
pending receipt of another command frcmi the user FTP that 
specifies required information. 

4. 4xx - Transient negative reply (RPC-765, pg 276) 

The commeind has not been EKJcepted and requested action did not 

take place. The error condition is temporary and the user FTP 

should reissue the command or return to the beginning of the 
command sequence. 
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' 5. 5xx - Permanent negative completion reply {fiPC-765, pg 277) Vv 

The ccanmand has not been accepted and the requested action did 
not take place. The user FTP should not repeat the exact 
command or ccmimand sequence. 

b. The second digit of the reply code shall indicate functional 
grouping with one of the following \^lues: (RFC-765, pg 277) 

1. xOx - Syntax error {RFU-765, pg 277) 

These replies refer to syntactically correct consnands that don't 
fit any functional category, or are unimplemented or 
superfluous. 

2. xlx - Information (RFtC-765, pg 277) 

\^ These replies are for requests for information such as statiis or V^ 

help. 

3. x2x - Ckannections (RFC-765, pg 277) 

These replies refer to the TELNET and data connections. 

4. x3x - Authentication and siccounting (RFC-765, pg 277) 
These replies are for the login process and accounting. 

5. x4x - Unspecified (RFC-765, pg 277) 

6. x5x - File system (RFC-765, pg 278) 

These replies indicate the status of the server FTP file system 
based upon the requested transfer or other file systan action ^^^^^ 
\jl requested by the user FTP. \3 
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\J^ c. The third digit, least significant, shall give a more precise ^l^ 

meaning to eeich of the function categories specified by the first 
and second digit defined in above subsections a. and b. (RFC-765, 
pg 278) 

The text associated with the following listed replies is only a 
recommendation; however, the first and second digit shown are 
mandatory and shall not be changed. (RFC-765, pg 278) 

The third digit of the reply codes shall be used with the first and 
second digit of the reply code functional groups as follows: 
(RPC-765, pg 278) 

1. 200 Command OK (RFC-765, pg 278) 

2. 500 Syntax error, command unrecognized. (RFC-765, pg 278) (The 
above may include errors such as command line too long. ) 

3. 501 Syntax error in parameters or arguments. (RFC-765, pg 278) 

4. 202 Command not implemented, superfluous at this site. 
(RFC-765, pg 278) 

5. 502 Command not implCTiented. (RFC-765, pg 278) 

6. 503 Bad sequence of ctMnmands. (RFC-765, pg 278) 
7, 504 Command not implemented for a parameter, (RFC-765, pg 278) 
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(^ 8. 110 Restart marker reply. (RFC-765, pg 278) (j 

The text of the above shall be exactly as shown below: 

MARK yyyytSP] = [SP]nBnram 

vAiere yyyy is the user FTP data stream marker and 
mnanm is the server FTP equivalent marker. 

9. 119 Terminal not available (RFC-765, pg 279) 
The above is not applicable per SOW. 

10. 211 System stattis or system help reply. (RFC-765, pg 279) 

11. 212 Directory status. (RFC-765, pg 279) 

12. 213 File status. (RPC-765, pg 279) 

13. 214 Help message. (RFC-765, pg 279) 

■ |) (Text on how to use the server or the meaning of a particular Mjj 

non-standard command. This reply is useful only to the human 
user.) 

14. 215 [scheme] is preferred scheme. (RFC-765, pg 279) 
The above is not applicable per SOW. 

15. 120 Not implemented. 

16. 220 Service ready for new user. (RFC-765, pg 279) 

17. 221 Service closing TELNET connection. (RFC-765, pg 279) 

18. 421 Service not available, closing TELNET connection. 
(RFC-765, pg 279) 

This may be a reply to any ccsionand if the FTP server knows it 
must shut down. 

o o 
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19. 125 Data connection already open; transfer starting (RFC-765, 
pg 279) 

20. 225 Data connection open; no transfer in progress. (RFC-765, 
pg 279) 

21. 425 Cannot open data connection. (RFC-765, pg 279) 

22. 226 Closing data connection. (RPC-765, pg 279) 

Requested file action successful (for exan^ile, file transfer or 
file abort) . 

23. 426 Connection closed; transfer aborted. (RPC-765, pg 279) 

24. 227 Entering Passive Mode. (RFC-765, pg 279) 

25. 230 User logged in, proceed. (RFC-765, pg 279) 

26. 530 Not logged in. (RPC-765, pg 279) 

27. 331 User name okay, need password. (RFC-765, pg 279) 

28. 332 Need account for login. (RPC-765, pg 279) 

29. 532 Need account for storing files. (RFt>765, pg 279) 

30. 150 File statiis okay; about to open data connection. (RFC-765, 
pg 279) 

31. 151 User not local. (RFC-765, pg 279) 
The above is not applicable per SOW. 



o 






"^.. 
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) 32. 152 User unknown; mail will be forwarded by the operator. 



O 



(RFC-765, pg 279) 

The above is not applicable per SOW. 

33. 250 Requested file action okay; completed. (RPC-765, pg 279) 

34. 350 Requested file action pending further information. 
(RFC-765, pg 279) 

35. 450 Requested file action not taken; file unavailable. 
(RFC-765, pg 279) 

(for exanple, file busy) 

36. 550 Requested action not taken; file unavailable. (RPC-765, 
pg 279) 

(for example, file not found, no access) 

\^ 37. 451 Requested action aborted; local error in process. \^ 

(RFC-765, pg 280) 

38. 551 Requested action aborted; page type unknown. (RPC-765, 
pg 280) 

39. 452 Requested action not taken; insufficient storage space in 
system. (RPC-765, pg 280) 

40. 552 Requested file auction aborted; exceeded storeige allocation 
(for current directory or dataset). (RFC-765, pg 280) 

41. 553 Requested action not taken; file name not allowed. 
(RFC-765, pg 280) 



o o 
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42. 354 Start mail input. (RFC-765, pg 280) ((3 

TTie above is not applicable per SOW. 

A numerically ordered list of reply codes can be found on page 
280 of RPC-765. 

3.6.2.2.2 Sequencing of Ckamraands and Replies (RFC-765, pg 287) 

The communication between the user FTP and the server FTP shall be an 
alternating dialog implemented as follows. 

a. The FTP shall issue commEinds to the server FTP and shall wait for a 
reply before sending further commands. {RPC-765, pg 287) 

b. The receiver FTP shall send one or more replies to the user FTP for 
each received command. (RPC-765, pg 287) 

c. The specific OCMIAND-REPLY sequences shall be as stated below. 
(RPC-765, pg 287) 

NOTE: In the subsections d. through k. below each ccHnmeind is listed and is 
followed by possible reply codes. Preliminary replies are listed 
first with succeeding replies indented under them. Then positive and 
negative ccanpletion, and finally intermediary replies with the 
remaining commands from the sequence following. 

d. Connection Establishment (RFC-765, pg 287) 

120 

220 
220 
421 ~ 



x..,^' 
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e. {This subparagraph not vised) 

f . Login (RFC-765, pg 288) 

1. USER {RFC-765, pg 288) 

230 

530 

500, 501, 421 

331, 332 

2. PASS (RFC-765, pg 288) 

230 
202 
530 
500, 501, 503, 421 



230 
202 
530 
500, 501, 503, 421 

g. Logout (RFC-765, pg 288) 

1. QUIT (RFC-765, pg 288) 

221 
500 



o 



O 332 ^ O 

3. ACCT (RFC-765, pg 288) 
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2. REIN (RFC-765, pg 288) 

120 

220 
220 
421 
500, 502 

h. Transfer jKirameters (RPC-765, pg 288) 

1. VCm (RPC-765, pg 288) 

200 

500, 501, 421, 530 

2. PASV {RPC-765, pg 288) 

227 

500, 501, 502, 421, 530 

3. MODE, TYPE, and STRU {RPC-765, pg 288) 

200 

500, 501, 504, 421, 530 

i. File action conimands (RFX>-765, pg 288) 

1. REST (RPC-765, pg 288) 

500, 501, 502, 421, 530 
350 
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C^ 2. STOR (RPC-765, pg 289) 

125, 150 

(110) 

226, 250 

425, 426, 451, 551, 552 
532, 450, 452, 553 
500, 501, 421, 530 

3. RETR (RPC-765, pg 289) 

125, 150 

(110) 

226, 250 

425, 426, 451 
450, 550 
500, 501, 421, 530 

4. LIST (RFC-765, pg 289) 

125, 150 

226, 250 

425, 426, 451 
450 
500, 501, 502, 421, 530 

5. APPE (RPC-765, pg 289) 

125, 150 

(110) 

226, 250 

425, 426, 451, 551, 552 
532, 450, 550, 452, 553 
500, 501, 502, 421, 530 

o © 
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6. RNFR (RFC-765, pg 289) 

450, 550 

500, 501, 502, 421, 530 

350 

7. RhJTO {RFC-765, pg 289) 

250 

532, 553 

500, 501, 502, 503, 421, 530 

8. DELE (RFC-765, pg 289) 

250 

450, 550 
^ ^ 500, 501, 502, 421, 530 

9. ABCB (RFC-765, pg 290) 

250 

500, 501, 502, 421 

(Note that the RFC contains an appsirent inconsistency. The 
command-reply sequence section for ABCM (RFC pg.48) indicates 
that 225 (data connection open; no transfer in progress) is an 
appropriate reply to ABQR. The ABOR caranand description (RFC 
pg.271) indicates that the data connection is always 
terminated. Since both are not possible, FTP will never respond 
to an ABOR command with a 225 . ) 
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C p j. Informational commands (RFC-765, pg 290) 

1. HELP (RFC-765, pg 290) 

211, 214 

500, 501, 502, 421 

k. Miscellaneoixs comraaiKis <RPC-765, pg 290) 

1. MX)P (RFC-765, pg 291) 

200 
500, 421 

3.6.2.3 Establishing Connections (RFC-765, pg 257, 282) 

Before the transfer of data can take pleice, the user and server processes 
■ J) must establish a TELNET connection for exchanging FTP commands and replies ^^ 
and a data connection over TAich files may be transferred. The establishment 
of these connections shall be as stated below. 

3.6.2.3.1 Establishing TELNET Connection (RFC-765, pg 282) 

a. The user process shall initiate the full-duplex TELNET connection. 
(RPC-765, pg 282) 

b. Ihe server process shall "listen" on port L for initiation of the 
TELNET connection. (RFC-765, pg 282) 

c. The TELMTT connection shall be closed by the server process at the 
user's request after all transfers and replies have been completed. 
(RPC-765, pg 282) 
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(f'\ d. The user and server processes shall follow the conventions of the (f ^ 

TELNET protocol specified in section 3.5 of this document. 
(RPC-765, pg 282) 

3.6.2.3.2 Establishing Data Connection (RFC-765, pg 257) 

a. The user process default data port shall be the same as the the 
TELNET control connection port; that is, port U. (RFC-765, pg 257) 

b. The server process default data port shall be adjacent to the TELNET 
control connection port, that is, port L-1. (RFC-765, pg 257) 

c. The passive process (user or second server) shall "listen" on the 
data port prior to sending a transfer request command. (RFC-765, 
pg 257) 

d. The server, upon receiving the transfer request, shall initiate the 

/^ > data port connection. (RFC-765, pg 257) ^ "^ 

e. The server shall accept alternate data port commands. (RFC-765, 
pg 257) 

f . The closing of the data port shall be by the server and shall be 
indicated to the user process by a reply. (RFC-765, pg 258) 

g. The server shall unconditionally close the data port connection 
under the following conditions: (RFC-765, pg 258) 

1. The transfer mode requires a close to indicate EOF. (RFC-765, 
pg 258) 

2. An abort ccanmand is received frcan the user. (RPC-765, pg 258) 
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3. The port specification is changed by the user. (RFC-765, §J) 
pg 258) 

4. The TELNET connection is closed legally or otherwise. (RFC-765, 
pg 258) 

5. An irrecoverable error condition occurs. (RPC-765, pg 258) 

3.6.2.4 FTP Transniission Modes (RFC-765, pg 258) 

The PTP shall provide three file transmission modes: one which formats data 
and allows for restart, one vdiich compresses data for more efficient data 
transfer, and one vAiich transfers the data with little or no processing. 

3.6.2.4.1 FTP Stream Mode (RFC-765, pg 259) 

a. The data shall be transferred eis a stream of bytes. (RFC-765, 

b. Record structure shall be allowed. (REX:-765, pg 259) 

c. For record structures, the FOR and EOF shall be indicated by a 
two-bj'te control code. The first byte shall be all ones, the escape 
character. The second byte shall be 1 for FOR, 2 for EOF, or 3 for 
EOR/EOF. Section 3.6.2.5.4 specifies the mapping FTP and NCS file 
structures. (RFC-765, pg 259) 

d. For file structure, the EOF shall be indicated by closing the data 
port connection. (RFC-765, pg 259) 

3.6.2.4.2 FIP Block Mode (RFC-765, pg 259) 

a. The data shall be transferred as a series of blocks preceded by one 
or more header bytes. (RPC-765, pg 259) 
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b. The header byte shall consist of descriptor code and a count field. 
(RPC-765, pg 259) .. 

1. The descriptor code (decimal) shall be as follows: (RFC-765, 
pg 260) 

128 = End of data block is BOR 
64 = End of data block is EOF 
32 = Suspected errors in data block 
16 = Data block is a restart marker 

Section 3.6.2.5.4 specifies the mapping between FTP and NOS file 
structures. 

2. The count field shall indicate the total length of the data data 
block. (RFC-765, pg 259) 

yy 3.6.2.4.3 FTP Compressed Mode (RFC-765, pg 261) \_y 

There are three kinds of information sent in ccanpressed mode as stated below. 

a. Regular data shall be sent in a byte string vAiere the first byte 
contains a count of the number of data bytes that follow. The count 
shall be >0 and <=127 with the MSB always 0. (RFC-765, pg 261) 

b. Compressed data shall consist of replication or filler bj^es. 
Replicated data shall be indicated by a first byte with the two MSBs 
of the first byte set to 10 followed by a 6-bit replication count, 
followed by the repeated character. Filler bytes shall be indicated 
by the two MSBs of the first byte being set to 11 followed by 6-bit 
count. The actual filler byte shall be a sjjace for ASCII and zero 
for Image data representation types. (RFC-765, pg 262) 

c. Control information shall be sent in two-byte escape sequences and 

\J shall be as described in 3.6.2.4.2.bl. (RFC-765, pg 261) l|^. 
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3.6.2.4.4 Restart Markers 

1. CYBER FTP will choose restart markers based upon the elapsed time 
since the last restart marker was transmitted. The elapsed time (in 
seconds) can be specified upon invocation of FTP, or if not 
specified then, by an installation selectable default time. The 
initial default will be 60 seconds. The FTP invocation parameter is 
RESTART=n v*iere n is the number of seconds. 

2. Restart markers will be based upon the current file, record, and 
byte number {bytes are 60 bits for TYPE L 60, 8 bits for all 
others). It will be of the following format: 

ffffffffff,rrrrrrrrrr,bbbbbbbbbb (format 1) 

-or- ffffffffff,rrrrrrrrrr,aaaaa,bbbbbbbbbb (format 2) 



ffffffffff 1:5) to 10 digit decimal nvimber identifying the file 
(NOS logical file) number, counting frcnn file 1. 

rrrrrrrrrr up to 10 digit decimal number identifying the 
record (NOS logical record) number, counting frcan 
record 1. 

bbbbbbbbbb up to 10 digit decimal number identifying the byte 
number at tAich to begin restart. If the byte 
count is larger than 10 digits then format 2 is 
used (see aaaaa parameter). 
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aaaaa tip to 5 digit decimal number identifying the 
high-order byte nxjmber. This number is prefixed 
to the bbbbbbbbbb parameter to obtain the total 
byte count. This parameter is present only if the 
byte count exceeds 10 digits. Note that the total 
byte cotmt cannot exceed 2**48-1 
(281474976710655). 

For all numbers, FTP suppresses leading zeros during marker 
generation and ignores any leading zeros sxipplied in the REST 
cc^nmand. 

3 . Example ( format 1 ) : If FTP chooses a restart marker in file 1 , 
record 10, bj'te 60 then FTP would send a marker (assxjme block mode) 
of the form: 

/■-'-\_ + + + _+ + +_ + ,/ -^ 

V_y {Descriptor! Byte Count = 7 { Marker | Marker ! Marker I V y 
ICode = 16 I I Char M' | Char ',' | Char '1' I 
+ + + + + + + 

1 Marker ! Marker 1 Marker | Marker | 

I Char '0' ' Char ',' ! Char '6' I Char '0' | 

+ + + + + 

The restart reply issued to the user by the remote FTP (assume 
non-CYBER) would be: 

110 MARK ?????? = 1,10,60 

where ?????? is the equivalent marker for the remote FTP and is 
host dependent. 
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^/) 4. Example (format 2): If FTP chooses a restart marker in file 356, 

record 2, byte 181474976710655 then FTP would send a marker (assume 
block mode) of the form: 



o 



-+ 

I 



Descriptor 
Code = 16 



Bji^e Ctount = 22 



Marker 
Char '3' 



^faL^ker 
Char '5' 



Marker 



! Char '6' 1 



Mairker 
Char ',' 



Marker I Marker 
Char '2' I Char ',' 



Msirker 
Char '1' 



Marker 
Char '8' 



Marker 
Char '1' 



Marker 
Char '4' 



Marker 1 Marker 
Char '7' I Char ',» 



ffeirker 
Char '4' 



I Marker 
I Char '9* 



Marker 
Char '7' 



Marker 
Char '6» 



Marker ! Msirker 
Char '7' ! Char *1' 



{ Marker 
I Char '0' 
.+ 



^farker 
C2iar '6' 



! Marker 1 

! Char '5' I 

.+ . + 



Marker 
Char '5' 



\^ 



The restart reply issued to the user by the remote FTP (assume 
non-CYBER) would be: 



o 



no MARK ?????? = 356,2,18147,4976710655 

where ?????? is the equivalent marker for the remote FTP and is 
host dependent. 

3.6.2.5 CYBER/NOS IMique Features 

The following subsections define the FTP canmand parameters and features that 
are unique to the CYBER hJOS implementation of FTP. 

3.6.2.5.1 NOS Pathname Parameters 



o 



A NOS pathname consists of a file name plus any legal permanent file access 
ccanmands Eind other psirameters. Some NC6 parameters are eillowed in FTP 
commands while other parameters are not. 
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Parameter 

AC=ac 

AL= level 

BR=br 

CT=ct 

M=m 

PN=packname 

ER=pr 

PW=password 

R=r 

S=space 

SS=subsystm 

t)N=usemame 

XD=expdate 

XT=exptime 



Description 

Alternate catlist access 

Access level 

Backup requirement 

File permit category 

File access mode 

Pack name 

Preferred residence 

File peissword 

Device type 

Minimum available space 

Interactive subsystan 

User name 

Password expiration date 

Password expiration time 



Applicable 
FTP Command(s) 

STCe only 

STOR only 

STCK only 

STOR only 

STOR/RETR only 

all, incl. LIST 

STOR only 

all, xcept SITE 

all 

STOR only 

STCffi only 

all, incl. LIST 

STOR only 

STOR only 



b. The following NOS parameters are not permitted: 
Parameter Description 



vy 



NA 
WB 
ET 



No abort 
Wait-if-busy 
Real-time processing 



c. The following FTP-unique parameters are permitted: 



Parameter 


Description 


Applicable 
b'iV Command{s) 


RTrrt 


CRM record type 


all 


MRL=mrl 


CRM maximum record length 


all 


FL=fl 


CRM fixed length 


all 


DA 


Dii*ect access 


all 


lA 


Indirect access 


all 


LO 


Local access 


all (local h'LV only) 


PF 


Permanent access 


all 


FSC=n 


File skip count 


RETR only 


READBOI 


Read-to-EOI flag 


RETR/SITE only 


CS=cs 


Character set 


all 


TRUNC 


Pad processing 


STOR/APPE/SITE 


PKHK 


CYBER to CYRKR defaults 


SITE only 



o 



(Note that these parameters are meaningless for the DELE, RNFR 
RNTO commainds . ) 



and 
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d. Many of the parameters listed above are meaningful only for direct 
access files. If ,a direct access file parameter is supplied (for 
example, "M") and the file is actually indirect access, the 
parameter is ignored and no warning is issued. 



o 



c 



e. The usage of the parameters listed in paragraph a, above, is defined 
in the NCS Reference Manual, Vol 3. Explanations of the FTP-unique 
parameters in paragrajdi c are in subsections 3.6.2.5.2 through 
3.6.2.5.7, below. 

3.6.2.5.2 C5?M Parameters 

CRM parameters are used to specify the desired record type to be used in 
CYBER FTP processing. 

a. The following parameters are permitted in the pathname and SITE 
ccanmand to specify C3?M information: 



Parana ter Description 

ET=n CSM record type; values are W, Z, or S, see table 
below for defaults 

MRL=nnn CTO! maximum record length; optional for STOR (write) 
on W records, optional for RETR (read) on W and S 
records, not used for all others, no default 

FL=nnn CRM full length; optional for STC»l/RETR on Z records, 
not used for all others, default is installation 
selectable but typically 150 characters 
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b. FTP will support three CRM record types: W (word-count), Z 
(zero-byte terminated), and S (hK3S system logical record). Ihe 
following table shows vdiich records are the default, and which are 
legal, for each FTP representation type: 



^^ — N^ 



+ + + J 

I Fl'P type 1 W 1 Z 


Y + 

, S ! 

I. J. 


I ASCII (6/12) ! X 1 D 1 X I 

+ + + + + 

1 ASCII (8/12) 1 D 1 - 1 X* 1 

1 Image | D ! - J X* { 


! Logical 60 I - ! - 

+ + + J 


D 1 

h + 



Key: X Combination is permitted 

D Default CTOl record for given FTP type 

* File may not duplicate for this combination 

- Combination is not permitted 

1. S-type records 



CRM S-type records correspond to NOS system logical records. No 
special data organization is assumed; the data is treated as a 
stream of 60-bit words. This can cause problems with files 
exchanged with foreign host systems (see it«n b. below). An 
advantage of this record type is that most system utilities will 
operate correctly with this type but not with W-type records. 
S-type records should be chosen when system utilities must be 
used to interpret the data (that is, utilities which don't 
support W-type records) and when the end of data can be 
distinguished from trailing zero filler without the need for a 
byte count . 



V.,y 
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2. W-type records 

CRM W-type records maintain a header that contains a character 
count. The (Mi v«ser never sees this header; it is stripped off 
by CSM before data is given to the Liser. An FTN program using 
standard I/O can take advantage of this also by using the FILE 
control statement to specify the W-type. Normal system 
routines, such as FSE, will incorrectly interpret this header as 
data. If systan routines must be used, FCa?M can be used to 
convert between record types (but then duplication problons, 
such as described in item b. below, may occur) . W-type records 
should be chosen vdien only liser programs will be used to 
interpret the data, and when the end of data can only be known 
by the byte count. 

The character count returned by CRM W-type records is in 6-bit 
characters. To convert frcsn 6-bit to 8-bit characters, use this ^^^^ 
\J formula: \j) 

i = INT(6j/8) where: i = # of 8-bit characters 

j = # of 6-bit chsiracters 
INT = integer truncation function 

To convert from 8-bit to 6-bit characters, use this formula: 

j = INT<8i/6) 

3. Z-type records 

CSa z-type records are used to delimit lines of extended disply 
code text, vdiere each line ends with a zero-byte terminator. 
All system utilities that do text processing (for example, FSE) 
use this record format. Z-type records should be chosen for 
text files, particularly vAien the files will be interpreted by 
Bj system utilities. ^^ 
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c. Two tyjje/record combinations may not permit exact duplication. For 
example, if the file is sent to a CYBER from an 8-bit machine, sent 
back to the 8-bit machine, and then the originsil and transferred 
files ccmpared, they may not be identical. 

Failure to duplicate occurs for an image or ASCII 8/12 
representation type with a S-type CRM record. In this case, \4ien 
CYBER FTP sends a file out, it interprets all trailing 8-bit bytes 
with a value of zero as padding, and does not send them. If a file 
was originally sent to the CYBER with trailing zero-bytes, these 
will not be rettimed (since they are interpreted as padding). Since 
S-tyije records have no way of identifying padding, this cannot be 
resolved. The default for image type files is a W-record, so if the 
user selects S-type records, the user must have scane way of 
determining the end of a file, or must know that no trailing 
zero-bytes exist, or must not care. 

y^' ASCII 6/12 files do not present a problen, since no character is '\ j 

represented as a zero-byte, and trailing zero-bytes can be freely 
interpreted as padding. 

3.6.2.5.3 NOS File Parameters 

NOS file parameters are used to specify the CYBEE file type to be used in FTP 
processing. 

a. NOS defines two types of permanent files, direct and indirect access 
files. Four keyword parameters have been defined in FTP to support 
these file types plus local files for local FTP users. The 
parameter can be siapplied as a pathname parameter or in the SITE 
consnand. The four keywords bt& PF, IA, DA, and LO, with no values. 
If IA is supplied, then the file will be read/written as an indirect 
access file. If DA is supplied, the file will be read/written as a 
direct access file. If LO is supplied, the file will be 
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\Ji read/written as a local file. If PF is supplied, the file will be 

readA-jritten as a permanent (indirect or direct access) file. The 
four parameters are mutually exlusive, resulting in a syntax error 
if more than one is supplied in the same ccamnand. 

b. If on a command, one of the keywords is supplied and the actual file 
type does not match, an error will be returned and the command will 
fail. 

c. If no keyword is specified, the action depends on vAiether the file 
already exists and on the current default file type. The normal 
default file type is instadlation selectable but is typically 
indirect access. "Die default can be changed by the SITE ccanmand. 
A default type of LO is always ignored (for both a read (RETR) and a 
write (STOR,APPE)) if the request comes from a remote xaser. A 
default type of lA or DA is always ignored for read requests frcan 
both local and remote users. A default type of lA or DA is ignored 

Cj) for write requests frcan both local and remote users if the file \^ 

already exists, in which case the current file type is used; if the 
file doesn't exist, then it is created with the default lA or DA 
file type. A default of LO for both local read and local write 
requests causes FTP to search for (or create) a local file. The EF 
parameter is primarily used to override a default of LO without 
having to specify lA or DA, and so is handled in the same way as 
lA/DA. 

d. When the default is ignored on a read, the file will be AlT^W31ed or 
GETted depending on the existing file type. Therefore, it is 
generally unnecessary in any ccanmand to specify a file tjTDe unless 
the user specifically requires a certain type. The following table 
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summarizes the different default type, user type, and operation 
combinations: 



o 



Request 


Operation: | Read (REIR) 


I Write 


_+ 

(STCK.APPE) 


Source 


Default Type ! File Exists 


! File Exists 

L 




No File Exists 


Local 


Indirect 


lA 


Actual ; Actual 




Indirect 




Direct 


DA 


Actual 


ActUEll 




Direct 




Local 


LO 


Local 


Local 




Local 




Permanent PF 


Actual 


Actual 




Indirect 


Remote 


Indirect 


lA 


* Actual 


Actual 




Indirect 




Direct 


DA 


Actual 


Actual 




Direct 




Local 


LO 


ActuEd 


Actual 




Indirect 




Permanent PF 


Actuad. 


Actual 




Indirect 



3.6.2.5.4 EOR/EOF Processing Parameters 

The ECK/EOF parameters allow FTP transfer of NOS multi-file files using FTP. 

a. NOS defines three types of file marks: EQR ( end-of -record ) , EOF 
(end-of-file) and EOI ( end-of - inf ormation ) . FTP only defines two: 
EOR (end-of -record) and IDF (end-of-file). The 1«)S and FTP EOR 
marks correspond, vAiile the NOS EOI corresponds to the FTP EOF. 
There is no FTP equivalent to the NOS EOF. 

b. I«)S FTP solves this problem by normally treating a NOS EOF as an FTP 
EOF. Since FTP will stop transferring a file vihen it receives an 
EOF mark, this implies that only one NOS file in a multi-file file 
will be transferred. Two parameters are supplied v*iich extend these 
capabilities: 



o 



FSCm File skip count. The default is zero (that is, the first 
file of a multi-file file will be transferred). If 
supplied, n NOS file marks will be skipped befoi^ transfer 
begins (that is, file n+1 of the multi-file file will be 
transferred). This parameter is meaningless for any 
command except RETR (or the source file of a SEND/REW 
command) and is ignored. 
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V.^ READEOI Read-to-EOI flag. If supplied, all files of the multi-file ^^ 

set will be transferred, with NCS EOF marks converted to 
FTP WM marks. This implies that the file cannot be 
duplicated if re-transferred to the CYBER; that is, the NOS 
EOF marks cannot be re-constructed. This parameter is 
meaningless for any command except RETR (or the source file 
of a SEND/RECV command) and is ignored. This parameter 
allows a user to transfer an entire multi-file file if NOS 
EOF marks are not important. 

c. CYBER-to-CYBER transfers can be done which preserve the NOS 
EOR/EDF/EOI structure using the PEER parameter on the SITE command 
(see SITE command). In this case, since FTP knows that the peer is 
another CYBER, the codes are interpreted differently so the standard 
FTP protocol can be used to identify NOS EOF marks. In this case, 
the FTP EOF code (2) is interpreted as a NOS EOF, the FTP EOF/BCK 
^^ code (3) is interpreted as a NOS EOI, and a NOS EOF/BDI is ^-v 

\^ represneted as two sepsirate FTP marks. V# 

3.6.2.5.5 ASCII Character Set Parameter 

The character set parameter allows selection of the ASCII code representation 
to be used during FTP processing. 

a. FTP supports two character sets: ASCII 6/12 (extended display code) 
and ASCII 8/12 (ASCII characters right- justified in 12 bits). The 
default character set is ASCII 6/12. If 6/12 is selected, the 
characters are converted between 6/12 and ASCII 8/8 using standard 
conversion tables from FOOPY. If Z-type records are selected, 
end-of -lines (CRLF) are converted to zero-byte terminators; 
otherwise conversion is chareuster-for-character with the full ASCII 
character set stipported. Note that the only end-of -line sequence 
supported for conversion to Z records is CRLF. If another line 
^^^ terminator is employed (for example, US or LFCR) then the file must ^,^ 

%J be transferred using 8/12 mode and converted using FCOPY. \J^ 
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b. The character set can be specified via a parameter in the jiathname 
or SITE command: 

CS=n Character set. n = "ASCII", "A", "ASCIIS", or "8". If ASCII 
or A Eu?e supplied then ASCII 6/12 is assumed. If ASCIIS or 8 
are supplied then ASCII 8/12 is assumed. The parameters 
corresp>ond to FSE parameters. The default local cheiracter 
set, if no character set is specified, is installation 
selectable but is typcially ASCII 6/12. This defaiilt can be 
changed by the SITE command. 

3.2.5.2.6 TRUNCate File Parameter 

a. The parameter TRUNC is defined for both the pathname and the SITE 
command. 

b. Although CRM is sufficient to handle an incoming file frcnn a foreign 
/- ^ host vAiich is then retransmitted to check duplication, it is not 
^ -^ sufficient to hsmdle a native CYBER file transmitted to a foreign 

host and then retransmitted to the CYBER. The TRUNC parameter is 
intended primarily to handle the case where an imsige file is being 
sent to a CYBER, and it is known that the file originally resided on 
a CYBER. For example, a file is transferred from a CYBER to an 
8-bit machine and then from the 8-bit machine to a CYBER. Suppose 
the file had only one 60-bit word. In the CYBER- to-remote transfer, 
an extra 4 bits of padding wsis inevitably added to the file to make 
it a imoltiple of 8-bit bytes. When the file is transferred to the 
CYBER, FTP will not know that the 4 bits sure pad, and will allocate 
another word with another 56 bits of padding. In this csise, the 
user should specify TESUNC, the 4 bits of padding will be dropped, 
and the file will be an exact duplicate of the original. 



O' 
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^rw^v 



^ 



c. If the TRUNC parameter is not specified and the default has not been 
changed by a SITE command then the word is filled out with 56 zero 
bits if a byte overflows into the next CYBER word. Note that TRUNC 
only applies to a 4-bit overflow. If one full byte or more is 
stored into the last CYBER word, the word is ah-reiys zero- filled 
regardless of viiether or not TRUNC is specified. Note that pad 
processing applies to every record in a file, not just the end of 
the file. 

d. If it is possible for zero-fill within a file to be confused with 
file data, or if the file is to be sent out again, a C3RM record type 
must be chosen that specifically identifies the padding bytes (see 
section 3.6.2.5.2). Otherwise, v4ien the file is sent to another 
host, the zero-fill will be sent as data, or a program reading the 
file may interpret the zero-fill as data. 

e. The TRUNC parameter is not required for TYPE L 60 transfers or SITE 

(^ NOS PEER transfers, since TRUNC will automaticeaiy be eissumed. It fj) 

is also generally not required for ASCII files, unless the trailing 
character (s) of records in the file can be mistaken for zero-fill 
padding. For 6/12 ASCII files, this is not possible, since no 
character uses the zero-byte for its representation. 

3.6.2.5,7 CYBER-to-CYBER Transfers 

This section describes FTP methods for facilitating CYBER-to-CYBER file 
transfers. 

a. In addition to the ASCII (A) and Image (I) representation tjpes, FTP 
supports a Local Bj-te tj'pe. The form of the command is: 

TYPE L 60 
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[1 U b. Note that only a value of 60 is supported; other values will be (|^ i) 

rejected. If this type is specified, FTP will assumed that all data 
received will be a multiple of 60 bits. For example, if 8 bj-tes 
(8-bit bytes) are received for a complete treinsmission, the last 4 
bits will be discarded. Normally, using other representation types, 
a second word would be created containing the 4 bits and 56 bits of 
zero padding. This parameter wets eidded to make it eaisier to send 
files CYBER- to-CYBER and ensure that the files are exact duplicates. 
In this mode, only system logical records (S-type) can be selected, 
but since the files are exact duplicates, any type file will be 
successfully moved, including W-type, indexed sequential, etc. 
Therefore, if the KT psirameter is specified other than S with an L 
60 type transfer, it will be ignored with a warning message. It is 
recommended that the SITE NOS PEER command be issued to ensure 
identical transfer of file meurk information also. (Reference 
section 3.6.2.1.1, SITE Command.) 



v^ ,y' 



"">, 



3.6.3 External Interfaces {RFC-765) 

The following subsections define the FTP external interfaces. Interfaces eu:^ 
provided for direct user call of FTP and for application calls to FTP. 

3.6.3.1 Application Program (RFC-765) 

The Application Program interface shall be provided by FTP to application 
programs written in FORTRAN or any language that can interface to FORTRAN 
(for example, SYMPL and COBOL) . The FTP Control Statenent interface shall 
use this interface to access the FTP capabilities. In the following 
discussions, the term 'standard_character' string is used to refer to a 
PCS?TRAN character string or to an array of 60-bit words that contains 
left- justified characters, zero-filled and zero-byte terminated. A 
standard_character string uses the 6/12 display code representation, so the 
display code escape characters (ceiret and at-sign) will always be interpreted 
as such. If a standard_character string can contain n characters, then the 
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calling routine should allocate 2n 6-bit bytes (10 bytes per 60-bit woixi) for 
the worst case of all lower case characters. The term 'nanie_character' is 
used to refer to the character subset consisting of alphabetic (A-Z), ntmeric 
(0-9), minus sign (-), and period (.) characters. 



o 



3.6.3.1.1 FrP_Accept_Reply (FTPAR) Routine (RFC-765) 

The FrP_Accept_Reply routine shall return the full text-response to the last 
request issued. This routine can also be used to wait for completion of 
requests that were previously issued with no_wait. The calling format shall 
be: 

CALL FTPAR (connection_id, no_wait, last_conimand, reply, reply_code, 
more_reply) 



o 



connection id 



FTP connection identifier. Integer value supplied by 
the application. This must be the identifier 
returned by FTP in the FrP_Connect request. The 
application uses this value to distinguish between 
different FTP connections simultaneously established. 



o 



no wait 



Indicates no waiting for ccanpletion. Boolean value 
supplied by af^lication. If true, the routine will 
return immediately if the previous request has not 
completed. The application must then call 
FrP_Accept_Reply again later to determine the reply. 



last ccHisnand 



Last conraiand issued by the application, A 
standard_character string returned by FTP containing 
the 4-character command; parameters originally 
supplied with command are not returned. 



o 



(6443WA'P33) 



CXKTROL DATA FRI\^ATE 



3-96 



O 



HKSYSlM-OOa-ERS-OO-C 
10 December 1986 

(| J) reply Textual reply frcan coimection attempt. A 

standard._character string returned by FTP containing 
up to 80 characters of reply text. The text for 
replies from a CYBER FTP, either local or remote, is 
specified in section 3.6.2.2.1. Reply text from 
other FTP implementations is defined by that 
implementation. This value is undefined if 
reply_code is zero or negative. 

reply_code Reply code from previous request. Integer value is 

returned by FTP for completed requests regardless of 
success. Reply codes are defined in section 
3.6.2.2.1. Reply code is zero or negative if no_wait 
is specified and operation is currently in progress. 

more_reply Indicates the reply text is continued on another line 

(80 character array). Boolean value returned by 

/-" \ .^ ^ 

) FTP. If true, a subsequent call to FTP_Accept_Reply 

will return the next line of the message. When the 

last line is read (more_reply false), a subsequent 

call to FTP_Accept_Reply will return the first line 

of the response. 

3.6.3.1.2 FrP_Connect (FTPC) Routine (RFC-765) 

The FTPC routine is called to begin an FTP session. All ranote hosts 
involved in the session (a maximtrai of two, for third-party transfers) must be 
specified in the single call. The entire FTP session can be terminated by 
calling FTPD, or FTPC can be called again to specify a new session. The 
format of the FTPC command is: 

CALL FTPC {host_address, host2_address , no_wait, 
connect_id, connect 2_id, reply_code) 



c 



(6443W/WP33) OCMTROL DATA PRIVATE 3-97 



o 



HKSYSlW-OOa-ERS-OO-C 
10 December 1986 

host address 



Address of renvote host. A standard character string 
supplied by the application containing up to 24 name 
characters. The name can be an internet address or a 
domain name. If a domain name is supplied, FTP will 
determine the internet address. If the string is 
empty or blank, the local host is assumed. If an 
internet address is supplied, it must be delimited by 
brackets (for example, [10.0.3.19]). 



o 



host2 address 



o 



no wait 



Address of second remote host. The same rules apply 
as above, if this parameter is used. This should be 
zero if the transfer is between the local host and a 
r«note host specified by host_address. The 
host2_address should be the address of the second 
host if the transfer is between two remote hosts; 
that is, a third-party transfer. 

Indicates no waiting for completion. Boolean value 
supplied by application. If true, the routine will 
return immediately after issuing the request. The 
application must then call FTP_Accept_Reply to 
subsequently determine the reply. 



o 



connection id 



o 



Remote host FTP connection identifier. Integer value 
is returned by FTP for successful connections and 
must be supplied on subsequent FTP calls to identify 
the specific connection. The connection id for the 
local host is always 1. A connection to the local 
host is always assumed. However, in a third-party 
session, no file trsmsfer ccanmands can be directed to 
the local host. Only the HEUP, QUIT, REIN, and NOOP 
coiranands can be sent to the local host during 
third-party sessions. 



© 
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connect2_id Undefined if a zero host2_address is specified. 

Otherwise it contains an integer value, sis above, 
used to identify the third-pairty connection. 

reply_code Reply frcan connection attanpt. Integer value is 

returned by FTP for all connection attempts 
regardless of success. Reply codes are defined in 
section 3.6.2.2.1. If the application requires the 
message text, the FrP_Accept_Reply routine must be 
called. Reply code is zero or negative if no_wait is 
specified and operation is currently in progress. 

Any commands directed at -remote hosts are checked by FTPI, as feir as 
possible, for correct syntax and for correct entry given the current state. 
FTPI advances the state depending on responses frcMn the conHnands. 
lAisupported commands (that is, specified in FTP RFC, but not supported by 
CYBER implementation) are passed vmexamined with no state change. 
Unspecified ccanmands (commands not in RFC) are rejected by FTPI as 
erroneous. The states of the two transfer connections are both checked. For 
example, a RETR command cannot be sent to a remote FTP (in a two-party 
session) if the local host has not first been sent a STOR command. The SITE 
command is given special processing as defined in section 3.6.2. 1.1. 2f. 

3.6.3.1.3 FTPJDisconnect (FTPD) Routine (RFC-765) 

The FTPJDisconnect routine shall request the FTP Protocol Interpreter to 
terminate a the established connections. TTie calling format shall be: 

CALL FTPD ( no_wait, reply_code ) 

no_wait Indicates no waiting for completion. Boolean value 

supplied by application. If true, the routine will 
return immediately after issuing the request. The 
application must then call FrP_Accept_Reply to 
subsequently determine the reply. 
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reply_code 



Reply from disconnect attempt. Integer value is 
retiimed by FTP for all attempts regardless of 
sxxxDess. Reply codes are defined in section 
3.6.2.2.1. If the application requires the message 
text, the FTP_Accept_Reply routine must be called. 
Reply code is zero if no_wait is specified and 
operation is currently in progress. 



o 



3.6.3.1.4 FTP_Status (FTPS) Routine 

The FrP_Status routine shall retiim the current status of an FTP connection. 
The calling format shall be: 



CALL FTPS 



o 



connection id 



{ connection_id, in_progress, host_address, 
user_name, account, data_type, file_structure, 
transfer_mode, pathname, reply_code ) 

FTP connection identifier. Integer value supplied by 
the application. This must be the identifier 
returned by FTP in the FTPjConnect request. The 
application uses this value to distinguish between 
different FTP connections simultaneously established. 



\J 



xnjprogress 



Indicates if a command is currently in progress. 
Boolean value returned by FTP is true if the user has 
issued a ccaranand that has not yet ccanpleted. 



host address 



Address of remote host. A standard_character string 
returned by FTP containing up to 24 name_ch£iracters . 
This is the name supplied to FTP in the FrP_Connect 
request. 



O 
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Name of viser. A standard_chauracter string returned 
by FTP containing up to 80 characters. This is the 
string supplied on the last USER ccanmand. If no USER 
commands has been issued, the string will be all 
blanks. 



o 



account 



Account data. A stand£ird_character string returned 
by FTP containing up to 80 characters. This is the 
string supplied on the last ACCT command. If no ACCT 
cc»nmand heis been issued, the string will be all 
blanks. 



data_type 



.; 



file structure 



Current representation type. A standard_chau7acter 
string returned by FTP containing up to 80 
characters. This is the string supplied on the last 
TYPE ccanmand, or the default if no command was 
issued. 

Current file structure. A standard_character string 
returned by FTP containing a single character. This 
is the character supplied on the last STFiU ccanmand, 
or the default if no cxHranand was issued. 



transfer mode 



Current transfer mode. A standard_chai-acter string 
returned by FTP containing a single character. This 
is the chau:"acter supplied on the last MODE conmand, 
or the default if no cooBiiand was issued. 



pathname 



Current pathname. A standard_character string 
returned by FTP containing up to 80 characters. This 
is the string supplied on the last REIE or STCSl 
command. 



o 
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reply_code 



Reply to status request. Integer value is returned 
by FTP for all attempts regardless of succsess. Reply 
codes are defined in section 3.6.2.2.1; however, this 
reply code indicates only viiether the given 
connection exists. 



o 



3.6.3.1.5 FTP_Send_(:kMiBiiand (FTPSC) Routine (RPC-765) 

The FrP_Send_ConBnand routine shall send an FTP command over the specified FTP 
connection. FTP shall maintain user protocol state tables for each 
connection established. If a ccsnmand that is invalid at a particular state 
is issued, FTP shall reject the ccMnmand with an appropriate reply. Ccanmand 
parameters shall also be examined to ensvire they conform to syntax 
specifications. No atteinpt is made to check syntax or state on ccamnands not 
supported by the CYBER FTP. llie calling format shall be: 



o 



CALL FTPSC (connection_id, command, no_wait, i^ply_code) 



connection id 



FTP connection identifier. Integer value sxjpplied hy 
the application. This must be the identifier 
returned by FTP in the FTP_Connect request. The 
application uses this value to distinguish between 
different FTP connections simultaneously established. 



o 



ccanmand 



FTP ccwnnand to be issued. A standard_character 
string supplied by the application can contain any 
number of characters. The command string should 
include any required parameters. If the application 
does not supply a TELNET line termination sequence, 
FTP will append it to the aid of the command. 



o 
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no_wait Indicates no waiting for completion. Boolean value 

supplied by application. If true, the routine will 
return immediately after issuing the request. The 
application must then call FrP_Accept_Reply to 
subsequently determine the reply. 

reply_code Reply from command. Integer value is returned by FTP 

for all attempts regardless of sticcess. Reply codes 
are defined in section 3.6.2.2.1. If the application 
requires the message text, the FTP_Accept_Reply 
routine must be called. Reply code is zero or 
negative if no_wait is specified and operation is 
currently in progress. 

3.6.3.2 Cksntrol Statement {RPC-765) 

^-^ The Control Statement interface shall be provided by FTP to terminal user ^ — ^ 
Vy jobs, batch jobs, and CYEER Control Language (CCL) procedures. If the V ^ 
control statement is invoked from a terminal, the program shall perform a 
diadogue with the user, displaying replies as they are received and sending 
cc»iimands as they are entered. All parameters are order-independent. The 
fonnat of the control statement shall be: , 

FTP (I=command_file, L=output_file, NA, PC=prefix_char) 

command_f ile Name of loced file containing FTP coranands . If 

omitted, file I>3IVr is assumed. If the file is 
sussigned to a terminail, FTP may perform an 
interactive dialogue with the user, depending on the 
output_file. If 1=0, FTP will take commands frcsn 
subsequent lines of the current control statanent 
file. FTP commands are distinguished frcm control 
statCTients by the prefix character specified by the 
„, PC pa]~ameter. ^^ 

o o 
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output_file 



Name of file to receive FTP messages. If emitted, 
file OUTEUr is assijmed. These messages consist of 
command replies from FTP processes with established 
connections. If the file is assigned to a terminal 
and command_file is also assigned to a terminal then 
FTP will perform an interactive dialogxje with the 
user. If L=0, output messages are discsurded. 



NA 



No-abort jjarameter. If specified, FTP will continue 
to read and process commands even if errors are 
encountered; normally FTP will abort the user if 
errors are encountered in a ccanmand file that is not 
assigned to a terminal. This parameter has no 
meaning for interactive users. 



o 



prefix_chsur 



Canmand prefix character. This character must 
precede all commands vdiich are anbedded in the 
control statement file following the FTP statement. 
If emitted, asterisk (*) is assumed. 



o 



The complement of FTP standard ccanmands available and their syntax is 
specified in section 3.6.2.1.1. 

The cc»iraands and syntax described below apply only to control statanent 
users. Users of the application-cadlable routines, and peer FTPs, must 
adhere to the CYBER FTP protocol standard and runtime calling conventions. 

a. An OPEN cranmand is defined. This command specifies the FTP hosts 
involved in the session. The format of the comnand is: 

OPENESP] [HOST] [SP3 tH0ST2] 



o 



At least one blank must separate each of the fields. If a host name 
itself must contain blanks, the entire host name must be delimited by 



o 
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quotation marks (") or dollar signs ($) (the standard NOS 
delimiter). If the host name is delimited, and the host name itself 
contains the delimiter character, it must be entered twice in 
succession to distinguish the real use of the character from the 
delimiter. 

The 'HOST' field is always required. It specifies the name of the 
ranote host for the file transfer. If 'H0ST2' is omitted, the file 
transfer will take place between the local host and the remote host. 
If 'H0ST2' is supplied, the file transfer will take place between 
'HOST' and 'H0ST2' , A file transfer between two remote hosts is 
called a third-party transfer. 

The internet address can be entered explicitly if the host name is 
unknown or if the site host name table does not list the host. An 
internet address must be enclosed in brackets (for exarrple, 
[10.0.7.23]). Use of internet addresses is discouraged. 

b. The OPEM command can only be entered as the first command, or after 
the CLOSE cormnand. The CLOSE command terminates the FTP connections 
by sending a QUIT command to all remote hosts, without terminating 
the connection with the local host. CLOSE can be used to allow more 
than one FTP session during a single invocation of FTP. CLO^ takes 
no parameters. 

c. Canmands entered after the OPEN are directed to a specific FTP host 
that is either specified in the command or assumed from the default. 
The default host after an OPEN command is always the local host. The 
default can be changed using the HOST command. The format of the 
HOST command is 

HOSTCSP][HCBT] 
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) where 'HCDST' is the name of the default host. It must match either \J 

the 'HOST' or 'H0ST2' parameter specified in the last OPEN command, 
or must have the value 'LOCAL' or null to specify the local host. 
The 'HOST' parameter can contain a unique contiguous subset of the 
name specified in the OPEN command. For example, if the following 
open command were issued: 

OPEN SRI-NIC. ARPA SRI-NCC.DDN 

then 'HOST NIC would refer to the first host, while 'HOST DDN' would 
refer to the second. The command 'HOST SRI' is in error because the 
string is non-unique, 

d. A command can be directed to a non-ctefault host by specifying '©host' 
before the command. For exarrple: 

OPEN SRI-NIC. ARPA SRI-NCC.DDN [the default host is LOCAL] 

\j @NIC USER anonymous \^ 

@^!IC PASS 

@>JCC LBER anonymous 

@NCC PASS 

HOST NIC [the default host is SRI-NIC] 

LIST [list catalog at host SRI-MIC] 

A unique contiguous subset of characters can be entered for the host, 
just like the HOST command. 

e. Certain commands always assume the local host regardless of the HOST 
command. These are QUIT, CLOSE, OPEN, HOST, and HELP. Of these 
commands, only the HELP command can ever be preceeded by the ©host 
prefix; an ©host preceeding any of the others is ignored. 



o o 
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f . "Hie QUIT command operates the same as the CLOSE command, except that 
the local FTP connection is also terminated, the FTP control 
statement terminates, and control returns to NOS. 



\J 



g. Ckammands and host names can be entered in upper and/or lower case. 
Care should be taken with ccanmands directed to non-CYBER hosts, since 
upper and lower case may be significant for certain command 
parameters. Upper and lower case is insignificant for any FTP CYBER 
command or parameter. For example, the following two ccHiimands are 
equivalent: 

ppEn Sri-nic.arpa 
Open SRI-NIC. ArPa 






h. Commands can be entered as the standard 4-character representation, 
the full representation, or as a \jnique abbreviation. A tmique 
abbreviation is any truncated version (that is, trailing characters 
deleted) of a command that cannot be mistaken for another command. 
The valid commands are listed below: 



V. 







h'iV Standard 


Minimum IMique 




Full 


(4-character) 


Abbreviation 




OPEN 


n/a 







CLOSE 


n/a 


C 




HOST 


n/a 


HO 




SEND 


n/a 


SE 




RECEIVE 


n/a 


REC 




RENAME 


n/a 


REN 




HKTP 


HKTP 


HE or ? 




QUIT 


QUIT 


Q 




REINITIATTZK 


REIN 


REI 




ABCHT 


ABCXi 


AB 




SITE 


SITE 


SI 




NOOP 


NOOP 


N 




USER 


USER 


U 




PASSWORD 


PASS 


PASS 




ACCOUNT 


AOCT 


AC 




PCKT 


PCKT 


PO 




PASSIVE 


PASV 


PASV or PASSI 


o 
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G ™. .. , . O 





1-TP Standard 


Minimum Unique 


Full 


(4 -character) 


Abbreviation 


MODE 


MODE 


M 


TYPE 


TYPE 


T 


STRUCTURE 


STRU 


STK 


RESTART 


REST 


RES 


STCSJE 


STCm 


STO 


RKi'KIEVE 


REIR 


RET 


LIST 


LIST 


L 


APPEND 


AfPE 


AP 


RNtK 


RNFK 


RNF 


RNTO 


RNTO 


RNT 


DKLKrE 


DELE 


D 



A ccHonand directed at a remote host that is not supported by CYBER 
FTP (for example, STAT) can be entered only as the foxor-character 
FTP standard - abbreviations are not supported for these commands. 

i . A pair of commands has been defined to make it eeisier for the user 
to perform standard file transfers. They are SE(«3D and RECEIVE. The 
g^ format of the SEND command is: #^ 

SEND[SP3 [local_pathname] [SP] [remote_pathname] 

This command has the same effect eis would the two comnands: 

eiocal_host RETR local_pathna]ne 
eraDote_host STCR resnote_pathname 

The format of the RECEIVE command is: 

RECETVEESP] [local_pathname] [SP] [remote_jpathname] 

This comnand has the same effect as would the two cc»iinands: 

er«nDte_host RETO refflote_pathname 
@local_host SKJR local_pathname 



o 
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For both SEND and RECEIVE ccHnmands, at least one blanlt must separate 
each field. If a pathname contains a blank, the pathname must be 
delimited by quotations (") or dollar signs ($). If the pathname is 
delimited, aiwi the pathname contains the delimiter character, each 
occurrence of the character must be repeated to distinguish frcan the 
deli m iter character. 

In third-party transfers, the localjiost is the first host specified 
in the OPEN, and the remote-host is the second host sjjecified in the 
OPEN. 

An error is issued if the ©host parameter is prefixed to SEND or 
RECEIVE. 

Use of the STCK/RETR cojnmands v*ien SEND or RECEIVE will work is 
discouraged since the ojjportxmity for user error is much greater 
^ ^^ with the former. _^ 

j. The RENAME command is defined as an alternative to the RNFR/RNTO 
sequence. Pathnames containing blanks must be delimited, just as 
for host names. The format of the command is: 

RENAME [ SP]new_pathname [ SP] old_pathname 

This command has the same effect as the following two ccmroands: 

RNFR old_pathname 
RNTO new_pathname 

Use of the RNFR/RNTO cojiBnands is discouraged since the opportunity 
for user error is much greater. 



o o 
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^_y k. The prefix character is required before commands only if the control 

statanent file is used (1=0 on FTP control statement). For 
interactive input, or other input files, it is not required but can 
be sv^plied. 

1. Comnients can be placed in the cranmand stream by starting the line 
vdth two consecutive prefix characters. Extra blanks can be used 
between parameters, and blank lines between ccmraiands, to improve 
readability. 

For example: 

«* Get DDN host name table. 

OPEN SRI-NIC. ARPA 

^^ ** Convert to standard NCS 6/12 display code. ^^^ 

o ■ o 

SITE CS=ASCII 

*» Log into network host. 

©NIC USER ANONYMOUS 
©NIC PASS GfUEST 

RECEIVE DDNHOST <NEriNPO>HOSTS.TXT 

QUIT 

m. Commands can be continued by beginning continuation lines with two 
periods ( . . ) , but canmands can only be broken between parameters ; 
parameters thanselves cannot be broken onto another line. For 
example: 

OPEN 
.. SRI-NIC.ARPA 
\j) .. SRI-NCC.DDN O 
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vJ Note that in a command file, viiere the first character must be a \j 

prefix character, the above sequence woiald be as follows: 
* OPEN 

*.. SRI-NIC. ARPA 
*.. SRI-NCC.DDN 

The excess blanks are not required. The above sequence could also 
be entered as: 

*OPEN SRI-NIC.ARPA 
*..SRI-NIC.DDN 

n. If an interactive viser break (for example, CIKL-T) is entered, the 
user is polled with the following: 

FTP command XXXXXX in progress, -or- FTP Idle. 
Do you wish to abort? (Y or N): 

The first message issued depends on vdiether a command is being 
processed at the time the user entered the user break. If the user 
enters 'N' in response to the prompt, processing continues. If the 
user enters 'Y' , an ABCe command is sent to both (or three) FTP 
hosts, followed by a QUIT. When these ccsmnands have ccmpleted, the 
FTP control statement aborts. 

3.6.3.3 DDN/C170 Application Interface (RFC-765) 

FTP shall utilize the DDN/C170 Application Interface to access DDN. Section 
3.8.3 defines the DDN/C170 Application Interface primitives. The following 
services of the Application Interface shall be used: 

1) TCP Primitives with optional TELNET protocol processing. 

2) Host name server translation and error reporting. 

3) DDN error logging. 

o c 
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) 3.6.3.4 NOS File System (RPC-765) \J 

FTP shall use the NOS file syston to access, ci'eate, and modify files as 
required by the FTP function. The NOS file functions are provided by the 
Permanent File Manager (PFM) , Loced File Manager (LFM), and Ctombined 
Input/Output (CIO) functions of NOS. The assembly language macro interfaces 
to these functions are defined in the NOS Reference Manual, Volune 4. The 
higher-level language interface to these macros, provided by SRVLIB, shall be 
used by FTP vdierever possible. 

3.6.3.5 FTP Peer Protocol (RPC-765) 

FTP shall implement the caranunicate with remote FTP processes using the peer 
protocol specified in section 3.6.2. 

3.6.3.6 Network Definition File (RPC-765) 

\^ FTP shall define its NAM application parameters via NDL configuration \jl 

directives. The directives used are defined in subsection 3.6.8. 

3.6.3.7 Operator Interface 

FTP sheill allow the operator to exercise some control over vdiich messages are 
written to the log file. The following are the K-display HOP cranmands used to 
control nessages written to the log file. 

K.DE = FTP Write error messEiges only to the log file 
K.DB = FTP Write debug and error messages to the log file 
K.RS = FTP Write statistics, debug, and error messages to the log 
file 

Error messages are always written to the log file regardless of anj^ operator 
intervention. 

O O 
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If the application has been loaded using NETIOD, the K.RS command will also 

restart AIP statistical gathering. 

3.6.3.8 HELPLIB Interface 

The Help text for FTP shedl be maintained in HELPLIB, in the following CCL 
procedures: 

FTP Help for FTP control statement users. This procedure will 
define help for the FTP control statanent parameters. This 
help is obtained by entering the HELFME.FTP command to }i06. 

FTFUSER Help for FTP local command users. This procedure will define 

help for FTP commands issued fran a local FTP control 

statement. It will be organized frc»n the viewpoint that the 

user is familiar with CYBER systems. This help can be accessed 

/- N directly throxogh the HELPME,FTPUSER crannand to NOS, or , n 

"^-^ indirectly through the HELP ccranand during a local interactive ^ " 

session with FTP. 

FTPPEER Help for FTP remote command users. This procedure will define 
help for FTP commands issued from a remote peer FTP. It will 
be organized frcan the viewpoint that the user is not familiar 
with CYBER systans. This help can be accessed directly throvigh 
the HELFME, FTPPEER command to NOS, or indirectly throvigh the 
HELP command during a session with a remote CYBER FTP (the help 
text originates frcan the remote CYBER). 

Procedures within HELPLIB are maintained as a viser library, beginning 
with a ULIB record and ending with an OPLD record, so the module that 
searches for a HELP topic can locate a procediore using the OPLD 
directory. 



o 
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f ]) The help text within the procedures is divided into topics vdiich are \^ 
delimited using standard CCL syntax: 

.HELP.topicl. 

Help text for topic 1 . 

.HELP,topic2. 

Help text for topic 2. 

etc. 

Each topic name is in upper case only, though the FTP/SMTP session user 
can enter the topic in both upper/lower case since FTP/SMTP will force 
it to upper case. A topic can be up to 10 characters in length. Topics 
can appear within the procedure in any order, since the structure of the 
procedure may require sets of help topics to appear in embedded 
sub-procedures (procedures following a .DATA directive). This will be 
(^ necessary since OCL regards the .HELP topics as CCL parameters. The \ji/ 
module that sesurches for a help topic must locate the appropriate 
procedure (for exan^ple, FTPPEER) and then do a sequential search for a 
'.HELP, topic' line until an WM is reached; no other assumptions can be 
made. 

The help text itself is in upper/lower case 6/12 display code. 
Conversion to/frcxn 8-bit ASCII for reanote users is done by FTP/SMTP. No 
conversion is required for local visers. 

A help text line must be limited to 70 characters in length. When 
possible, a single topic should contain no more than 20 lines of text - 
if more lines are required, a sub-topic(s) should be created if 
possible. Since HELP is intended primarily to be helpful, the 20 line 
limit can be exceeded to any length, if necessEuy to maintain 
helpfulness. The limits are given to permit help text to fit on any 
terminal screen, and to sjjare hard-copy terminal users a long wait 
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during printouts. The letst line in the help text body will always 
be a cross-reference entry 'See also: tl, t2, t3, t4, ..., tn.* 
vJiere tn are other related topics . Tlie help text body must always 
use correct English and correct punctuation. 

3.6.4 Internal Interfaces (HEiX^TBS) 

The following subsections describe the interfaces between the major 
ccanponents of CYBER FTP. The internal interfaces identified are: 

Protocol Interpreter to File Server 
Application Interface to Protocol Interpreter 
C!ontrol Statement to Application Interface 

3.6.4.1 Protocol Interpreter to File Server Interfeu^e (Rrc-765) 

Ihe Protocol Interpreter to File Server (PI/FS) interface consists of 
caranands and eissociated responses passed via a NAM connection, vdiere the 
commands are issued by the PI and responses are returned by FS. These 
ccanmands instruct the FS about file transfer processing to be performed. 
Although many of the cc»nmands are similar or identical to the FTP protocol 
ccanmands, PI does provide some processing for FS, as follows: 

a) All ccaranands/responses are issued in upper-csise display code only. 
This frees the FS from character-set concerns for command 
processing. (RFC-765) 

b) FTP Ckjnnection state tables are maintained by PI. The FS need be 
concerned only about the relevance of a conmand within its own 
state. (RPC-765) 



c 
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c) All parameters have been broken out and processed. This frees the 
FS from syntax analysis concerns for command processing. In the 
case of NCS-specific information (for example, packname, user 
number), PI inserts this information into a standard PFM FET that is 
passed to FS. (RFC-765) 

3.6.4.1.1 PI/FS NAM Connection (RFC-765) 

PI always initiates the NPt\ connection with FS. This connection request is 
issued as a result of an FTP user, either remote or local, establishing a 
connection with the local FTP host; if a local FTP user does not require a 
file transfer to or from the local host system (that is, a three-party 
transfer) then no file server is assigned. The standard connection 
acc^tance/ refusal criteria for NAM are arployed. An FS will only acc^t a 
single connection, since an instance of FS is dedicated to a particular FTP 
user, whether local or remote. Instances of FS which have been initialized 

Oby NW as part of start-up will NETON and wait for a connection request. g-y 
File Servers will be started by the protocol interpreter. This is ^-^ 
accomplished using the 'request startable' feature of tm^. When protocol 
interpreter requires a file server, it will request an A-A connection with 
FS; NWi in turn will start a copy of FS. 

A single file server will usually be idle and rolled out waiting for a user 
so that users won't have to *«it on file server Job startup. When protocol 
interpreter is initiated, it will request a connection with the server. When 
the file server becomes assigned to a user, protocol interpreter will request 
another connection with a server, and that server will become the new idle 
server. If more than one user rec^jests a server within a short period of 
time (1-2 seconds), then one of the users will have to wait until the another 
file server has initiated. 
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A given invocation of file server will only be used to handle a single user. 
That is, a file server is assigned to an FHTP user and when that FTP user 
terminates (QUITs), the file server will also terminate. This h^Dpens as 
follows: a) when the user terminates, protocol interpreter waits for any 
in-progress file transfer to conplete and then sends a quit message to FS, 
and b) File server closes its connection with FS when the quit command is 
received, and c) File server terminates (that is, 'goes away') when its 
connection with protocol interpreter is closed, whether by problems or 
deliberately as a result of the quit command. Note that the same file server 
remains assigned even if the user switches accounts with subsequent USER 
commands. Both the PI and the idle FS process are rolled out when not busy, 
to be rolled back in by NW when connection requests are received. 



O 



3.6.4-1.2 PI/FS Commands (RFC-765) 



V 



Commands to FS are passed as data over the NPM connection. Only one command 
may be passed in a single OTPUT, and a single command may be spread over more 
than one QTPUT, The general format of a command is: 






>9 




35 






17 




COriiAND 




t 
1 






















1 


LENGTH I 


1 

DATA i 

_____ ( 



COMMAND: 4-character, left- justified, zero-filled, upper-case 
display code identifying the command. 

LENGTH: 18-bit, right-justif ied, zero-filled, integer identifying 
the length of the command/data block. The length includes 
the command and length words. 
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DATA: Blcxsk of data associated with command. Format is specific 
to the command. 

The following ccanmands are defined: 

Data Word Data Description 

The MODE command specifies the FTP file transfer mode as defined by FTP. The 
specified mode will remain in effect until the next ^DDE conmand or until the 
connection is closed. 

1 of 1 Left- justified, zero-filled single character 'S', 'B' , or 
'C . Character has same meaning as FTP ^DDE consnand. 

The Tn=E command specifies the FTP file transfer type eis defined by FTP. "Hie 
specified type will remain in effect until the next TYPE ccanmand or until the 
connection is closed. 

O " o 

1 of 2 Left-justified, zero-filled, two-character field consisting 

of 'AT', 'AC, 'AN', 'L', or 'I'. Characters have same 
meaning as FTP TYPE command. 

2 of 2 Right- justified, 60-bit integer. Number passed with TYPE if 

TYPE = L, otherwise zero. 

The STRU command specifies the FTP file transfer structure as defined by 
FTP. The specified structure will remain in effect until the next STRU 
ccsnmand or until the connection is closed. 

1 of 1 Left- justified, zero-filled character 'F' or *R' . Character 
has same meaning as FTP STE?U ccaranand. 

The RETR conanand instructs FS to acquire the specfied permanent file and 
begin sending it across the TCP data connection according to the currently 
■ J defined type, structure, and mode. \^ 
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1 of n Left- justified, zero-filled, two-character field defining the 

file type. The following values are allowed: 'lA* for 
indirect access file, 'DA' for direct access file, 'PF' for 
either direct or indirect access file, and 'LO' for local 
file. *LO' is treated by FS the same as 'lA', since the PI 
creates a temporary indirect access file that is described in 
the FET below. If 'PF' is specified, FS will attempt to 
acquire the file either eis direct or indirect access . 

2 thru n WM. f onnatted File Environment Table (FET) . This table will 

contain all the parameters specified by the user for the 
file. In the C8ise of a local file, it defines a temporary 
I^errnanent file created by PI for the file transfer. 

The STOR coiranand instructs FS to create the specified permanent file and 
place into it data received from its TCP data connection according to the 
currently defined type, structure, and mode. 

1 of n File type. See RETR coimnand. If 'PF' is specified, 'DA' 

will be assumed. If 'LO' is defined, STOR will create an 
indirect access file as defined by the FET helaw vihich PI 
will then use to create a local file. If a loced file is 
specified, the destination must be the local user; remote 
users cannot create local files. 

2 thru n PFM FET. See RETTR command. 

The AFPE comnand instructs FS to append data received from its TCP data 
connection to the specified permanent file, according to the currently 
defined type, structure, and mode. 



\J' 



V, ..-'■ 
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X_J 1 of n File type. See RETR ccmnand. If 'LO' is defined, APPE will 

append the data to an indirect access file created by PI and 
containing the local file data, which PI will then use to 
restore as the appended local file. If a local file is 
specified, the destination must be the local user; remote 
users cannot append local files. 

2 thru n PFM FET. See RETR command. 

The RENM ccanmand instructs FS to rename the specified permanent file. This 
ccaranand is the cc«nbined FTP commands RNTO and RNFR. 

1 of n New permanent file name, left- justified, zero-filled. 

2 thru n PFM FET. See RETR ccannand. This FET is the format required 

by the PFM CHANGEE ccmnnand. 

\J The DELE ccanmand instructs FS to delete the specified permanent file. Vi^ 

1 of n Unused. This word is maintained for consistency with the 

other PF ccxnmands. Local files cannot be deleted. 

2 thru n PFM FET. See RETR command. 

The LIST ccxnmand instructs FS to obtain a catalog of the specified user 
accoxmt and to send it over the data connection. 

1 of n Loc£lI Flag. Ctontains an integer. Value is 1 if the request 

is from a user on this host; zero otherwise. 

2 thru n PFM FET for CATLIST ccamiand. 

The PORT ccanmand instructs FS to initiate a TCP data connection on the 

specified port. An existing connection will be terminated. ^^ 

O O 
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\J 1 of 1 Internet address and port. A 48-bit, right- justified, \J 

zero-filled field containing the internet address and TCP 
port in 6 8-bit fields, as specified by IP protocol. 

The PASV command instructs FS to initiate a passive TCP open on a 
TCP-assigned connection and to return that connection port as a response to 
the comnand. 

1 of 1 Internet address and port. A 48-bit, right- justified, 
zero-filled field containing the internet address and TCP 
port in 6 8-bit fields, as specified by IP protocol. The 
port number will be zero; TCP will assign a port. 

The USER command instructs FS to switch to the indicated user account. llie 
charge and project numbers have not been validated. 



\ 



1 of 3 User Number. A 1-7 character display code string. 



J left-jtistified and zero-filled. (^ ^ 

2 of 3 Family Name. A 1-7 character display code string, 

left- justified and zero-filled. 

3 of 3 Peussword. A 1-7 character display code string, 

left- justified and zero-filled. 

The ABOR command instructs ES to stop any ongoing transfer of data, close all 
network connections and terminate. No data is passed with the ABOR ccanmand. 

The NAM upline supervisory message INTRAJSR/R, sent from PI, will be 
interpreted as an ABCK command by FS. 

The QUIT command instructs FS to accept no further ccxnmands frcan PI, finish 
any unccanpleted commands, and terminate. No data is peissed with the QUIT 
command. 
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The REIN ccMimand is functionally identical to the QUIT conrniand. 

The AC!CT connnand instructs FS to charge file transfer activitiy to the 
specified accoxmt. 

1 of 3 Charge Number. A 1-10 character display code string, 
left- justified and zero-filled. 

2,3 of 3 Project Number. A 1-20 character display code string, 
left- justified and zero-filled. 

The REST ccHnnand instructs FS to perform the subsequent file transfer 
request as a restart from the location indicated in the data block. 

1 of 3 File number. An integer value identifying the liOS logical 
file number to begin restart, counting from file 1. 

\J^ 2 of 3 Record number. An integer value specifying the NDS logical \j) 

record number within the file to begin restart, counting from 
recoid 1. 

3 of 3 Byte nvonber. An integer value specifying the byte number 

number within the record at vdiich to begin restart. 8-bit 

bytes are assvaned. Note that the total byte covint cannot 
exceed 2**48-1 (281474976710655). 

3.6.4.1.3 PI/FS Responses (RFC-765) 

Responses to PI are passed as data over the NAM connection. Only one reponse 
may be passed in a single NETPUT, and a single response may be spresui over 
more than one NETPUT. At leeust one response is required for each conmemd 
sent by PI. If more than one response is required, these are sent as 
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(f Ji intermediate replies prior to the final reply. The general format of a 



response is: 



i9 




41 




17 




RESKJNSt 




1 
1 







! 













LENGTH ! 


DATA 5 

- - > 



FESPON^: 3-character, left- justified, upper-case display code 
identifying the FTP response number. 

LENGTH: 18-bit, right-justif ied, zero-filled, integer identifying 
the length of the response/data block. The length 
includes the response and length words. 



v._y 



DATA: Block of data associated with response, 
specific to the response. 



Format is 






The following responses are defined: 



Data Word 



Data Description 



Response 



110 



1 of n File number. Right justified, display code number of the 

file currently being received. 

2 of n Record number. Right justified, display code number of the 

file currently being received. 



'A 



3 of n Byte nu(Tt>er -1. Right justified, display code portion of the 
byte number currently being received. This is the portion of 
the number greater than 10 decimal digits. 
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Cj 4 of n Byte number -2. Ri^t justified, display code portion of the \^J 

byte number currently being received. This is the least 
significant 10 decimal digits of the number. 

5 of n Omracter count. 60-bit binary integer coxmt of the number 

of characters in the following sender restart marker. 

6 thru n Sender restart marker. Left justified string of characters 

received as rest£u:t marker. 

Response 550 

1 thru 3 PFM error text. The display code text returned by the 
permanent file manager explaining this error. 

3.6.4.2 Application Interface (AI) to Protocol Interpreter (PI) (RFC-765) 

|j) The Application Interface to Protocol Interpreter (AI/PI) interface consists \J) 
of requests and associated responses passed via a NAM connection, vAere the 
requests are issued by the AI and responses are returned by PI. AI issues 
requests containing FTP commands for processing by PI, or for forwarding to a 
remote FTP PI for processing. Minimal processing is performed by AI other 
than to pacdtage parameters supplied by an application into a request packet 
to be sent to PI, and to unpack responses received frcan PI to be returned to 
the application. 

3.6.4.2.1 AI/PI NAM Ckannection (RFX;-765) 

AI always initiates the NAM connection with PI. This connection request is 
issued as a resialt of an FTP application issuing the first FIP_Connect 
request. Subsequent FrP_Connect requests are passed over the same AI/PI 
connection; that is, only a single NAM connection exists between AI and PI 
regardless of the number of FTP connections established by the application. 
The connection is terminated by PI vAien an FTP_Disconnect request is issued 
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for the last in^P cx>nnection established by the application. The Application 
Interface resides in the application field length, so an AI/PI connection 
will exist for each application in the systeni that has established FTP 
connections. 



o 



3.6.4.2.2 AI/PI Requests (RFC-765) 

Requests to PI are passed as data over the M^ connection. Only one request 
may be passed in a single hETPUT, and a single request may be spread over 
more than one IsETPUT. The ^neral format of a request is: 






59 



REQUEST: 



XL 



REQUEST 



LENGTH 



PARAMETERS 



7--character, left- justified, zero-filled, upper-case 
display code identifying the request. 



LENGTH: 



18-bit, right- justified, zero-filled, integer 
identifying the length of the request/parameter 
block. The length includes the request and length 
words. 



PARPMETERS: Block of parameters associated with request. Format 
is specific to the reediest. All input parameters are 
packed consecutively in the block with no more than 
one parameter p&r word. Unless otherwise specified, 
the parameter values are identical to those specified 
in subsection 3.6.3.1. 
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^ The following requests are defined: 

Data Word Data Description 

The FTPC request solicits PI to establish an FTP connection with another 
FTP. If this is the first FTPC/FTPCS request issued since either the start 
of the program or since the termination of all previous FTP connections, then 
AI must establish the NAM connection with PI prior to issuing the request. 

1-3 of 3 Host_address. 

The FTPD request solicits PI to terminate a previoiisly established FTP 
connection. After completion, AI also terminates the NAM connection with PI. 

1 of 1 Connection_ID. 
The FTPS request solicits PI to send the current status of an FTP connection. ^^ 

o o 

1 of 1 C!onnection_ID. 

The FTPSC request sends an FTP ccmmand to PI for processing. Hie ccMnmand may 
be forwarded to a remote FTP or processed by the local PI depending on the 
COTBnand and the connection state. Multiple NETPUT requests may be required 
by AI to transfer the entire ccsnmand to PI, 

1 of n C!onnection_ID. 

2 thru n Ccanmand. 
of n 

In addition to requests issued for the standard AI routines, another 
intermediate request is defined vdiich the user does not initiate. ITiis 
request is the FTPLFS (FrP_Local_File_Saved request). If the application 
issues an FTP coranand (STCe or RETR) that involves a local file (that is, not 
permanent) then PI will issue a response to AI indicating that a local file ,^_ 
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must be saved as a permanent file so that FS C5an access the file. AI creates 
the permanent file and then issues the FTPLFS request to PI to indicate 
cofrpletion. 



O 



■V„. / 



1 of 9 PFM Status code. This is the cocte returned by PFM in 

response to the permanent file request. If non-zero, the 
request was unsuccessful. 

2 thru 9 PFM error message. This is an error message returned by 
of 9 R=T1 if the permanent file request was unsuccessful. 

3.6.4.2.3 AI/PI Responses (RFC-765) 

Responses to AI are passed as data over the NAM connection. Only one reponse 
may be passed in a single NETPUT, and a single response may be spread over 
more than one NETPUT. One and only one response is returned for each request 
issued by AI. The general format of a response is: 



59 



35 



17 



RESPONSE 


1 





LENGTH ! 


1 

I 

DATA i 

1 
.„ , , 1 



RESPONSE: 7-character, left- justified, zero-filled, upper-case 
display code identifying the response. 






LENGTH: 



18-bit, right- justified, zero-filled, ■ integer 
identifying the length of the response/data block. 
The length includes the response and length words. 



o 



DATA: 
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The follovdng responses are defined: 



o 



Data Word 



Data Description 



The FTPC response returns the results of an FTPC request. If an FTTC request 
fails and no other FTP connections exist, PI will close the NAM connection 
after returning this response. 



1 of 2 

2 of 2 



Connection_ID , 
Reply_code . 



%J 



The FTPD response returns the results of an FTPD request. If no other FTP 
connections exist, PI will close the NAM connection after returning this 
response. 




^tium^ 






^m^ 



rM^/^^"^- 
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1 of 9 Reply_code. 

2 thru 9 Reply, 
of 9 

The FTPS resjxanse returns information requested in an FTPS request. 

1 of 35 Reply_code. 

2 of 35 In_progress. 

3 thru 5 Host_address . 
of 35 

6 thru 14 User_naine. 

of 35 

15 thru 23 Acjcount. 

of 35 

24 of 35 Data_type. 

25 of 35 File_structure. 

26 of 35 Transfer_mode. ^^ 

27 thru 35 Pathname. Vy 
of 35 

The FTPSC response returns the results of the FTPSC request or FTPLFS 
request. If a ccHnmand is issued for a local file operation, PI may return an 
FTPSCSF response instead. 

1 of 1 Reply_code. 

The FTPSCSF response is retiamed in reply to an FTPSC request if local file 

action is required. If this response is received, AI must perform a PFM 

REPLACE using the FET supplied in the response. AI must then issue the 

FTPLFS request with the results of the PFW REPLACE. PI will then issue and 
FTPSC resjxjnse. 

1 thru n PFM FET to use in permanent file REPLACE request. 
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y^J 3.6.4.3 Control Statement to Application Interface (RFC- 765) \J) 

The Control Statement to Application Interface is implenented by the AI 
routines. These routines are used by FTP C/S to issue FTP requests on behalf 
of an interactive terminal user or NOS batch job. This interface is defined 
in subsection 3.6.3.1. 

3,6.5 Errors and Error Recovery (RPC-765, pg 262) 

There is no requirement for detecting bits lost or scrambled in data transfer 
since this level of error processing is provided by TCP. However, the FTP 
shall provide a resteirt capability as described below. 

3.6.5.1 FTP Restart (RFC-765, pg 262) 

The FTP sheill provide a restart capability for file transfers in the BLOCK 
and CCWFRESSED modes only. To siQ>port this capability, the FTP shall: 
O {Krc-765, pg 262) Q 

a. Insert a special marker code in the data stream that will have 
meaning to a receiver that implements restart. (RFC-765, pg 262) 

b. Use printable diaracters for the marker code in the defaiilt or 
negotiated language of the TELNET connection (ASCII). (RFC-765, 
pg 262) 

c. Recognize marker codes received frcan a sender process and issue 
restart commands to the sender to restart the process at the marker 
point. (RFC-765, pg 263) 

d. Restart a sending process upon receipt of a restart command from a 
receiver process. (RFC-765, p« 263) 



O O 
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3.6,6 Data Structures (RFC-765, pg 250) (fl) 

3.6.6.1 Data Representation and Storage (RFC-765, pg 250) 

The following data type representations types shall be provided by FTP. 

a. ASCII - This is the default type which must be supported by FTP 
implanentations. This data type shall also allow the user to 
specify: (RPC-765, pg 251) 

1. ASCII NCN-FRBJT - default format with no vertical format 
information used primarily for files destined for storage or 
processing. (RPC-765, pg 252) 

2. ASCII TELNET PC3?MAT CONTROLS - specifies that the file contains 
the TELNET vertical format controls of [CR] , [LF] , [NL] , [VT] , 
or [FF]. (RFC-765, pg 252) 

3. ASCII CARRIAGE CCKTROL - specif es that the file contains the 
following vertical control characters: (RFiC-765, pg 252) 

blank - move pajjer up one line 

- move paper wp two lines 

1 - move paper to top of next page 
+ - no movanent; that is, overprint 

b. IMAGiE - Data in this format are sent as contiguous bits. It is 
intended that this format be used for efficient storage and 
retrieval of files and for transfer of binary data. (RFC-765, 
pg 253) 

FTP shall assunte the default CYBER ASCII representation is in 6/12-bit 
display code. The SITE ccanmand shall be used to specify 8-bit ASCII or 6-bit 
display code. 
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V> 3.6.6.2 FTP File Structures (RFC-765, pg 254) ^^ 

FTP shall support the following file structures: 

a. File-Structure - files ^ere the file is considered to be a 
continuous sequence of data bytes. (RFC-765, pg 254) 

b. Record-Structure - files Uhere the file is made up of sequential 
records. (RFC-765, pg 254) 

3.6.6.3 FTP Numerical List of Responses (RFC-765, pg 280) 

A numerical list of FTP responses can be found in RFC-765, page 280. 

3.6.6.4 FTP Command Syntax (RFC-765, pg 285) 

OThe FTP cramnand syntax can be found in RFC-765, pg 285. jp^ 

3.6.7 Eqvdpnirat Configuration (RPC-765) 

FTP has no special equipment configuration requirements. 

3.6.8 Installation (HPC-765) 

The following subsections define the installation procedures and parameters 
for FTP. 

3.6.8.1 FTP Installation Procedure (RFC-765) 

FTP is installed losing the FTP build procedure and build verification is 
performed using the VFTP procedure. FTP should be treated as a Grovqj 3 job 
as defined in the JTOS Installation Handbook. It depends upon the DDN 
Supervisor Installation defined in subsection 3.8.8. The FTP product PL is 
^,1^ maintained in MODIFY format. The following files are created or updated by ^n^ 
\J the build procedure: JOBFTIP, JOBFTPS, HELPLIB ( updated ) , DNILIB ( updated ) . W' 
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3.6.8.2 FTP Installation Parameters (RPC-765) 



o 



The following installation parameters can be tailored for specific sites. 
Hiey Eire located in ccaranon deck OOWIPR. 

IPDLCS Default Local Character Set. This is the default character set 
for commands, responses and files at the locail CYBER host. 
Possible values are ASCII, ASCII63, and ASCII64 eis defined by 
the FOOPy statement. The default value is ASCII. 

IPFBTO File Busy Timeout. Ihis is the maximum time that FTP will wait 
for a busy file when the NA or V?B parameter is specified. After 
this period, the file transfer attempt will terminate. "Hie 
default is 600. 



IPFCTO FTP Ccxranand Timeout. This is the maximum time in seconds that 
FTP will wait for a remote FTP to respond to a command. After 
this period, the connection will be aborted. The default is 
600. 



V^' 



IPMBUF Maximum Buffer Size. This is the buffer size used for file 
transfers. The minimum size is the NAM dovmline block size (255 
words default). The default value is 10246. 

IFKTRY Retry Limit. This is the maximum retry limit for errors before 
FTP terminates the connection. 



>) 
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\Jl The following modify symbols can be specified using the *DEFINE directive to V^ 

influence the FTP build process: 

DEBIXJ If defined, FTP will generate AIP trace messages. 

IMS If defined, the FTP listing will contain Internal Maintainance 
information. 

STATS If defined, FTP will generate AIP statistics messages. 

3.6.8.3 Network Startup Master File {RFC-765) 

The following directives must be placed in the Network Startup Master File if 
automatic initiation of FTP is required. 

JOB(JOBFrPI,FTPI) 

\J 3.6.8.4 Network Definition File Directives (RPC-765) vJ 

The following table lists the DON applications and their configuration 
parameters: 







Number of 










Copies 


Request 




Name 


Description 


(Mxcopys) 


Startable 


Privileged 


FTPI 


Fl'P Protocol 
Interpreter 


1 


yes 


yes 


Kl'PS 


Fl'P File 
Server 


any{5) 


yes 


yes 


tTP 


Fl'P Control 
Statement 


any(5) 


no 


yes 


FTPA 


Fl'P User 


any(l) 


no 


no 




Application 
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^~\ The values for MXCJOPY can be adjusted by the site to control FTP usage. A 

small number can mean that FTP users will have to wait for resotirces viiile a 
large number can tie up TCP and NAM connections axid machine resources, 
affecting other users of the syTstem. 



o 



Additionally, FTP application users (FTPA) must provide OUTCALL directives to 
FTP for their applications. 

3.6.8.5 FTP Transmittal 

No other DDN CPCI transmittal can depend upon this transmittal. 



FTP Program Library (FTPnnnn) . This is an UPDATE formatted program 
library containing the FTP application interface routines, Protocol 
Interpreter, File Server and FTP Control Statement. The format of 
this program library is described later. ITie following object is 
generated from this PL: 



Name 



Tsse 



Location 



Description 



V._ 



FTPI 
FTPS 
FTP 
DNILIB 



Program 
Program 
Program 
Library 



System 
System 
System 
Syst«n 



NAMSTRT Procedxires un=NETOPS 



HELPLIB CCL Library un=LIBRARy 



FTP Protocol Interpreter 
FTP File Server 
FTP Control Statement 
FTP Additions to DDN 

Interface Library 
NAM Startup Proc. l^idate 

for FTPS/FTPI 

(JOBFTPI,JOBFrPS) 
FTP Help Procedures Update 

to HELPLIB 

( FTP/FTPPEER/FTPUSER ) 



o 



b. FTP Installation procedure (FTP). This procedure follows DECKOPL 
conventions to install FTP. 



c 
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\^ c. FTP Installation Verification procedure (VFIP). This procedure is \y 

to be executed on a newly-built system to verify that FTP has been 
properly installed. It does not verify that FTP actually works. It 
follows DECKOPL verification conventions. 

3.6.8.6 PL Structure 

a. Where deck lists are described as 'organized', it means that the 
decks are arranged in a SIMPLE manner logical with the structure of 
the program. For exanqple, the main program followed by all primary 
routines in alptobetical order followed by all minor routines in 
alphabetical order. If no structure can be identified, 'organized* 
degenerates to 'eilphabetized' , never to 'randcm' or 'complex'. 

b. FTP PL Structure. 

INFO 
O HISTC31Y \J 

[alphabetized comnon decks] 
-LIBSYMP- [contains *CWECB] 
[SYMPL library routines, alj^iabetized] 
-LIBCX»IP- [contains »CWEOK] 

[OOMPASS library routines, aljdiabetized] 

-SYMPL- [contains *CWEOR] 

-PISYMP- [enpty deck] 

[FTPI SYMPL routines, organized] 

-FSSYMP- [empty deck] 

[FTPS SYMPL routines, organized] 

-CSSYMP- [empty deck] 

[FTP CS SYME*L routines, organized] 

-COMPASS- [contains »CWBCK] 

-PIOCMP- [esmpty deck] 

O © 
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[FTPI COMPASS routines, alphabetized] 

-FSOOMP- [empty deck] 

[FIPS COIPASS routines, alphabetized] 

-CSOCMP- tanpty deck] 

[FTP CS COMPASS routines, alphabetized] 

-NAMSTCT- [contains *CWE(H] 

JOBFTPI 

JOBFTPS 

-HELPLIB- [contains *CWEOR] 

FTP 

[contains *CWEOR] 



O' 



-HECBl- 
FTPPEER 

-maR2- 

FTPUSEB 

-ENDPL- 



[contains »CWECR] 
[empty deck] 



NOTE: All non-library SYMPL/OOMPASS decks are ccMnpiled into a large 
library. The FTPI, FTPS, and FTP main programs are separately 
loaded using a LIBLDAD from that library. 

c. Inter-Component Ccxnmon Decks 

DDN System-Wide (defined in DDNTEXT) 



COMVDDN DDN General Runtime Interface Definitions 

OCMVDIP DDN Systan Installation Parameters 

OOWFET CIO FET Definitions 

OCWVFIT Crai FIT Definitions 

0»IV1PC IP Interface Definitions 

OOMVNCrr DDN NCT Definitions 

COMVSYS CYBER System Definitions 

0»IVTCP TCP Interface Definitions 

0(»IVTEL TELNET Interface Definitions 
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VV FTP X^ 

OCMVAPC FTP Application to Protocol Interpreter Interface 

COMVFTP FTP Definitions 

OOMVIPF FTP Installation Parameters 

OCMVPPC FTP Protocol Interpreter to File Server Interface 

OOWSSJ FTP ms Validation Interface 

3.7 Simple Mail Transfer Protocol (S^^P) (RFC -821/822) 

3.7.1 SfTP Abstract (RPC-821) 

The purpose of SMTP is to transfer mail reliably and efficiently, directly 
frcMn the sending user's host to the receiving user's host vdien the two hosts 
are connected to the same transport service. 

OThe SMTP will be inqslemented. on the CYBER host to provide sender and --„ 
r-ecipient SMTP functions for DDN users. CYBER SMTP, in conjimction with V>^ 
ranote host SMTP facilities, will provide the CYKK user and ranote host user 
with the capability to send and receive mail messsiges via DMi. Actusd 
delivery of the mail to a local mailbox is provided by a mail server 
application that uses the SMTP services. The model for SMTP lisage is 
depicted in Figure 3.7-1. ^ m/^ 



/rf 



l^flP is composed of four major components. ITie SMTP components are: ' ^/^^^ 



1) SMTP Protocol Interpreter (PI or SMPI) 

2) SMTP Application Interface (AI) 

3) SMTP Control Statement (CS or SMPC) 

4) SMTP Mail Server (SMPS) 



Protocol Interpreter is the primary SMTP module. It implements the protocol 
and performs all ccnsmmications with remote SMTP peers. In addition, it 
provides mail services to the CJontrol Statement and Mail Server through the ^^ 

o o 
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^^lication Interface. PI runs as a privileged system application program 
({^ and communicates with other SMTP corrponents via QTRM/Nm and permanent \J 

files. Communication with SMTP peers is perforrred using the C170 DoD 
Interface coffponent of the DDN Gateway CPCI. PI establishes TCP connections 
with remote peers to send outbound mail to remote hosts, and accepts TCP 
connections from remote peers to receive inbound mail from remote hosts. 

Application Interface provides a common interface between user or SMTP 
application programs and the PI. The SMTP Control Statement and Mail Server 
components use AI, as do site-specific mail servers or user a|:plications that 
wish to send mail. AI is a set of library procedures on DNILIB that are 
accessed using direct procedure calls. 

Control Statement provides a rudimentary method for interactive or batch 
users to send mail to other SMTP hosts, or to SMTP users on the local host. 
Since NOS does not provide a standard mail interface, CS is provided to 
perform this function. CS only sends mail and does not have provisions for 
reading incoming mail. Specific sites may choose to integrate their local 
mail systems with SMTP using AI, in which case CS is not required. 



.y 



Mail Serve r provides a rudimentary method for the delivery of mail destined 
for users on the local host. Since hDS does not provide a standard mail 
interface, SMPS is provided to perform this function. SMPS places irtoound 
mail into a user mail file which can later be read by the user. An 
installation option is available that makes the mail file corrpatible with the 
existing SES mail systan. 

The various SMTP components communicate via NAM connections that are d^icted 
in Fi^re 3.7-2. Each of the interfaces are numbered and correspond to the 
summaries below: 



/^'^. 
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1) Application programs issue requests to, and recseive information 
from, PI through QTRh connections established by AX. Two SMTP 
components, the Control Statement and Mail Server, are exasvples of 
such applications but user applications may also use mail services. 
Several instances of each kind of program, i.e. Control Statement, 
may be active at one time so that several connections (la, lb, Ic, 
Id) of this type may exist at one time. 



o 



o 



2) PI registers with the DoD AI to get host name translations, obtain 
comiTon host information, and log messages. This registration is 
obtained through the DoD AI, which creates a QTF?M/NAM connection 
with the DDN Supervisor. Only one such connection is created. 

3) PI opens active and passis/e TCP connections with remote SSiTP peers, 
using the DoD AI. DoD AI in turn qaens QTRM/NAM connections with 
the NP DoD G/W in the CDCNET MDI to obtain access to TCP services 
residing there. Many SMTP p^r connections can exist at one time. 

4) Mail data is exchanged between SMTP components, and stored for later 
retrieval, using permanent files maintained by NC3S and CRM. Access 
to these files is handled by SMTP AI for PI. There is an instance 
of SMTP AI for each instance of an SMTP User Application, SMTP Mail 
Server, or SMTP Control Statement. 
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System 1 
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SMTP 
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Figure 3.7-1. Model for 91TP Use 
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Figure 3.7-2. SMTP Functional Relationships 
3.7.2 SMTP Description (RFC-821, pg 2) 

Fi^re 3.7-1 illustrates a model of the SMTP in which the sender of mail 
establishes a two-way transmission channel to a receiver of mail. SMTP 
commands are generated by the sender and sent to the receiver and SMTP 
relies are sent from the receiver to the sender in response to the commands. 
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f ^ Once the transmission channel has been established and the sender and 

receiver have agreed that mail can be sent and delivered to the recipient, 
the sender sends the mail data. The sender then indicates the end of mail 
transfer and the receiver responds with a reply that the mail has been 
received and processed. 

The following subsections specify the requirements for the protocol between a 
sender and receiver SNTTP. 

3.7.2.1 SMTP Functions (RPC-821, pg 4) 

The CYBER SMTP shall provide sender and receiver electronic mail service such 
that SMTP mail transeictions may be accomplished. 

3.7.2.1.1 SMTP Sender Function (RFC-821, pg 4) 

As a sender, the CYBER SMTP shall: 

o ■■ o 

a. Initiate a new mail transaction by sending a MAIL coirnnaiKi to the 
receiver that identifies the sender. {RFC-821, pg 4) 

b. SeiKl a RCPT command(s) to the receiver to identify the mail 
recipient(s). (RFC-821, pg 4) 

c. Send a DATA command to the receiver followed by the mail data and end 
of mail indicator. (RFC-821, pg 5) 

d. Recognize and process receiver responses to a, b, and c above. 
{RFC-821, pg 4,5) 



fj) ^-^'^l o 
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3.7.2.1.2 SMTP Receiver Function (RFC-821, pg 4) 
As a receiver, the CYBER SMTP shall: 

a. Recognize the MAIL conraiand, reset state tables and buffers, and send 
a 250 OK reply to the sender if Euxiepted or an error reply if not 
accepted. {RFC-821, pg 4) 

b. Recognize the RCPT ccMnmand(s) and send a 250 OK reply if accepted or 
an error reply if not accepted. (RFC-821, pg 4) 

c. Recognize the DATA command and send a 354 intermediate reply if 
accepted and consider all succeeding lines to be message text. When 
the end of mail indicator is received and stored a 250 OK reply shall 
be sent to the sender. (RFC-821, pg 4) 

d. If the DATA command is not accepted an error reply shall be sent. 
(RFC-821, pg 5) 

e. Process the recipient(s) mail data. {RFC-821, pg 5) 

1. The receiver SMTP shall append mail data to the mail buffer. 
(RFC-821, pg 20) 

2. The receiver SMTP shall accept all of the 128 ASCII characters as 
mail data. (RFC-821, pg 20) 

3. The receiver SMTP shall recognize the end of mail data as the 
ASCII character sequence of [CRLF]"."[CRLF] . (RFC-821, pg 20) 

4. The receiver SMTP shall ensure that information in the 
reverse-path, forward-path, and mail data is cleared after 
delivery of the mail data. (RFC-821, pg 20) 
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5. The receiver S^^P shall insert at the beginning of the mail data 
a time stamp .J.ine (see exaji^le in 7 below) for all accepted 
messages delivered to a mailbox or relayed to the next SMTP. 
(RPC-821, pg 20) 

6. The receiver SMTP shall include the following information in the 
time stamp line (see example in 8 below): (RFC-821, pg 20) 

Identity of host sending the mail. 

Identity of host receiving the mail and inserting the time 
stamp* 

Date and time the mail was received, 

7. The receiver SMTP that makes the final mail delivery shall 

insert at the beginning of the mail data a retvim path line that ^„^ 
\jS preserves the information in the reverse-path from the MAIL VV 

command. (RFC-821, pg 20,21) 

NOTE: The following example of return path and received time 
stamps is provided for information. 

Return-path: <@GHI.ARPA,@DEF.ARPA,@ABC.Af?PA: JOE@ABC.ARPA> 
Received: from CKI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST 
Received: frcan DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST 
Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST 
Date: 27 Oct 81 15:01:01 PST 
FrcMn: Joe@ABC.ARPA 

Subject: In^iroved Mailing System Installed 
To: SA1@JKL.ARPA 

This is to inform you that ... 

O O 
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\J 8. The receiver SMTP shall provide a response for partially ((3 

successful processing following the end of mail data. The 
response shall be as follows: (RPC-821, pg 22) 

Send an CK reply in response to the DATA (XM4M®, (RFC-821, 
pg 22) 

Send an undeliverable mail notification to the originator of the 
mail that lists the recipients for vdiich mail could not be 
delivered using the MAIL OCMMAhJD. {RFC-821, pg 22) 

3.7.2.1.3 S^f^P Open/Close Function (RPC-821, pg 13) 

a. The sender S>rrP shall initiate the transmission channel connection, 
wait for a 220 reply from the receiver, and send a HELO ccanmand to 
the receiver to identify itself. (RPC-821, pg 13) 



b. The receiver SMTP shall send a 220 reply to the sender when the 
transmission channel connection is established and shall send 250 
reply to the sender in response to the HELD ccwmand to identify 
itself. (RFC-821, pg 13) 

c. The sender SMTP shall send a QUIT ccanmand to the receiver StJFP to 
close the connection. (RFC-821, pg 13) 

d. -me receiver SMTP shall send a 221 reply to the sender upon receipt 
of a ^JIT ccsranand and then close the connection. (RFC-821, pg 13) 

3.7,2.1.4 This subsection is blank to maintain paragraph numbering. 



V. 
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3.7.2.1.5 SMTP Command Syntax (RFC-821, pg 19) 



The SMTP commands define the mail transfer or the mail system function 
requested by the user. The syntax of all SMTP ccanraands shadl be as specified 
in a. through g. below. 

a. ShfTP commands shall begin with a coiranand code that shall consist of 
four alphabetic characters followed by an ASCII spsuie. {RPC-821, 
pg 19,27) 

b. Upper and lower cstse aljdmbetic characters shall be recognized 
equally in the ccnnmand code. (RFC-821, pg 27) 

c. An Eurgument field, if present, shall consist of a variable length 
character string following the command code. (RFC-821, pg 28) 

d. Upper and lower case aljdiabetic characters shall be recognized ^«v 
\J equally in an argument field. (RFC-821, pg 27) \J 

e. SMTP ccanmands without an argument field shall be terminated with an 
ASCII space followed by the ASCII character sequence of Carriage 
Return and Line Feed [CRLF] . (RFC-821, pg 19,27) 

f . SMTP command with an argument field shall be terminated with the 
ASCII character sequence of [CRLF] immediately following the 
argument field. (RPC-821, pg 28) 

g. No action shall be taken by the receiver of the SMTP command until 
the [CRLF] has been received. (RPC-821, pg 28) 

NOTE: The actual consnand codes, argument fields, and syntax of all SMTP 
commands to be implemented are stated in subsection 3.7.2.1.5.1. 

O O 
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\J 3.7.2.1.5.1 SMTP Commands (RFC-821, pg 19) f\ 

The SMTP commands described in subsections a. through h. below shall be 
implemented. {RPC-821, pg 29) 

NOTE: In the C3CMMAND PC8RMAT subsections a.l through h.l, items enclosed 
in brackets [] have the following meaning: 

[SP] - represents one ASCII space. 

[...] - represents a command argument. 

[CRLF] - represents the ASCII character sequence of Carriage Retxjim Line 
Feed. 

a. HELLO CCMMAND (RFC-821, pg 19) 



This command shall be sent by the SMTP sender to the SMTP receiver 
to identify the sender to the receiver. {RPC-821, pg 19) 

1. COMMAND POI^IAT - HELO[SP] [DOMAIN] [CRLF] {RPC-821, pg 29) 

HELD - The command code shall be the character string "HELO" in 
upper and/or lower case ASCII characters. (RFC-821, pg 19,27) 

DCMAIN - The DOMAIN argument shall be the name of the sender 
host computer. (RFC-821, pg 64) 

COMMAND EXAMPLE - HELO CDC-NOS.SNVL.ARPA 

2. The sending of this COTimand and receipt of an CXi reply from the 
receiver shall confirm that the sender and receiver are in the 
initial state in which there is no trans8W3tion in progress and 
all state tables and buffers are cleared. (RPC-821, pg 19) 



(6444W/WP35) CONTROL DATA HilVATE 3-146 



■^ -'■' 



o 



HKSYSlM-OOS-EIffi-OO-C 
10 December 1986 

b. MAIL COMMAND (RPC-821, pg 20) (j 

Ihis command shall be sent by the S>frP sender to the SMTP receiver 
to initiate a mail transaction in viiich the mail data will be 
delivered to one or more recipients. (RFXV821, pg 20) 

1. COmf^HD PCMIAT - MAILtSP] "FKDM:" [reverse-path] [CSILF] {RPC-821, 
pg 29) 

MAIL - The command code shall be the character string "MAIL" in 
upper and/or lower case ASCII charactei^. <RFC-821, pg 20,27) 

FRCM: [reverse-ijath] - The argument shall consist of the ASCII 
characters FSCH: followed immediately by the reverse-path. 
{RPC-821, pg 20) 

reverse-path - The reverse-path shall consist of an optional 
J^ list of hosts and a required sender mailbox. The sender mailbox B^ 

format is defined by the local mail server and shall not be 
restricted by SMTP, beyond the restrictions imposed on 
reverse-path. (RFC-821, pg 20) 

The list of hosts is a reverse source route and indicates that 
the mail was relayed through each host on the list with the 
first host in the list bis the most recent relay. This list is 
used as a source route to return non-delivery notices to the 
sender. Each relay host adds its host name to the beginning of 
the list and host names are separated with ccHnmas. The leust 
host name in the list is separated from the sender mailbox with 
a colon ":". 

The mailbox is the sender's mailbox and can be thought of as the 
return address of the originator of the mail. 

o o 
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Q) COMMAND EXAMPLE - MAIL FROM: <Yuma®CDC-NOS.SNVL.ARPA> f"\) 

- MAIL FROM: <@HOSTl.ARPA,@HOST2.ARPA:Yuma@CDC-N0S.SNVL.ARPA> 
c. RECIPIENT COMMAND (RFC-821, pg 20) 

This ccanmand shall be sent by the sender SMTP to the receiver SMTP 
to identify an individual recipient of mail data with multiple 
recipients specified by multiple use of this command. (RFC-821, 
pg 20) 

1. OCMWJD KMIAT - RCPTESP] "TO:" [forward-path] [CRLF] (RFC-821, 
pg 29) 

RCPT - The ccmmand code shall be the character string "KCFT" in 
upper and/or lower case ASCII characters. (RFC-821, pg 20,27) 

C ') TO: [forward-path] - The argunaent shall consist of the ASCII "^^ 

characters TO: followed immediately by the forward-path. 
(RFC-821, pg 20) 

forward-path - The forward-path shall consist of an optional 
list of hosts and a required destination mailbox. (RFC-821, 
pg 20) 

When the list of hosts is present, it is a source route and 
indicates that mail must be relayed to the next host on the 
list. When mail is relayed, the relay host must remove itself 
from the beginning forward-path and put itself at the beginning 
of the reverse-path. When mail reaches its ultimate 
destination, the forwEird-path contains only a destination 
mailbox and the receiver SMTP inserts the mail into the 
destination mailbox. See 3.7.2.1.4 for an example. 



c 
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\^ ;) COMMAND EXAMPLE - RCPT TO: <YumaJ@CDC-NK)S.SNVL> 

- BJFI TO: <@HOSTl.DDN,^OST2.DDN:Yuma@C3X>-l«)S.SNVL> 

d. DATA CX}MMAND (RFC-821, pg 21) 

This ccHnmand shall be sent by the sender SMTP and shall cause the 
receiver SMTP to interpret all following lines up to the end of mail 
indicator, [CRLF] . [CRLF] , as data from the sender SMTP. 

1. 0»WAND PCKMAT - DATA[SP]iaJLF3 (RPC-821, pg 29) 

DATA - The ccanmand code shall be the character string "DATA" in 
vipper and/or lower case ASCII characters. {RFC-821, pg 20,27) 

EXAMPLE - DATA 

(j e. RESET COMMAND (RFC-821, pg 25) \J> 

This coranand shall be sent by the sender SMTP and shall caxise the 
current mail transaction to be aborted. 

1. OC^MAND PC^MAT - RSETtSP] [CRLF] (RPC-821, pg 29) 

RSET - The conmand code shall be the character string "RSET" in 
upper and/or lower case ASCII characters. (RPC-821, pg 25,27) 

E3CAMPLE - RSET , 

2. The receiver SMTP shall send an CK reply upon receipt of this 
command. {RFC-821, pg 25) 



O ^ 
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\^ 3. The receiver SMTP shall discard all received mail data and shedl 

clear all buffers and state tables lapon receipt of this 
command. (RFC-821, pg 25) 

4. The sender shall discard all mail data and shall clear all 
buffers and state tables upon receipt of this ccanmand. (RFC-821, 
pg 25) 

f. HELP COMMAND (RFC-821, pg 25) 

This conmiand shall cause the receiver SMTP to send helpful 
information regarding SMTP implonentation to the sender of the HELP 
command. 

1. C<»1MA.ND FORMAT - HELP[SP][KEy WCM)][CRLF] (RFC-821, p29) 

HELP - the ccanmand code shall be the character string "HELP" in 
^;^^ upper and/or lower case ASCII characters. (RFC-821, p^25,27) 

KEY WSm - The KEY WCM> argument shall be an ASCII i:5>per and/or 
lower case character string that indicates the type of help 
wanted. 

The text for HELP topics are taken from OCL procedures. Three 
different HELP procedures are supported: 



SMTP 



Help for SMTP control statement users. This procedure 
will define help for the SMTP control statonent 
parameters. This help is obtained by entering the 
HELPME.SMTP ccanmand to NOS. 
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#^ SMPUSEB Help for SMTP local command users. "Ihis procedure will \^ 

define help for SMTP conHnands issued from a local SJITP 
control statement. It will be organized from the 
viewpoint that the user is familiar with CYBER 
systems. TTiis help can be accessed directly through 
the HELFME,SMPUSER ccanmand to NOS, or indirectly 
through the HELP command during a local interactive 
session with SMTP. 

SMPPEER Help for SMTP ronote command users. This procedure 
will define help for SMTP commands issued fron a renote 
peer SMTP. It will be organized frtxn the viewpoint 
that the user is not familiar with CYBER systons. This 
help can be accessed directly through the 
HELFME , SMrPPKKK command to NOS, or indirectly through 
the HELP conanand during a session with a ranote CYBER 
S^f^P (the help text originates frcan the remote CYBER). 
£\ Note that a local CYBER SMTP does not permit an ^j) 

interactive session with a ranote StfTP, but other 
systems may, and the user is not prohibited from 
logging directly into the SMTP frcxn a DDN terminal 
{that is, on a TAG). 

Procedures within HELPLIB are maintained as a user library, 
beginning with a ULIB record and ending with an OPLD record, so the 
module that searches for a HELP topic can locate a procedure using 
the OPLD directory. 

The help text within the procedures is divided into topics which are 
delimited using standard CCL syntax: 

.HELP.topicl. 

Help text for topic 1. 
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Q .HELP,topic2. ^ 

Help text for topic 2. 



V. ,y 



etc. 



Each topic name is in upper case only, though the SMTP session user 
can enter the topic in both upper/lower case since SMTP will force 
it to upi)er case. A topic can be up to 10 chsuracters in length. 
Topics can appear within the procedure in any oinier, since the 
structure of the procedure may require sets of help topics to appear 
in embedded sub-procedures (procedures following a .DATA 
directive). This will be necessary since CCli regards the .HELP 
topics as CCL parameters. The module that searches for a help topic 
must locate the appropriate procedure (for example, SMPPEER) and 
then do a sequential search for a ' .HELP, topic. ' line until an EOR 
is res«jhed; no other sussumptions can be made. 

Ilie help text itself is in upper /lower case 6/12 display code. 
Cksnversion to/from 8-bit ASCII for remote users is done by 
F^P/S^f^P. No conversion is required for local users. 

A help text line must be limited to 70 chsiracters in length. When 
possible, a single topic should contain no more than 20 lines of 
text - if more lines are required, a sub-topic(s) should be created 
if possible. Since HELP is intended primeu^ily to be helpful, the 20 
line limit can be exceeded to any length, if necessary to maintain 
helpfulness. The limits are given to permit help text to fit on any 
terminal screen, and to spare hsurd-copy terminal users a long wait 
during printouts. The last line in the help text body will always 
be a cross-reference entry 'See also: tl, t2, t3, t4, ..., tn.' 
where tn are other related topics. The help text body must always 
use correct English and correct punctuation. 
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^ The topics to be supplied include a general help discussion { .HELP. \^' 

conanand with no topic) , a topic called TOPICS which list all 
possible help topics, PARAMETERS v4iich lists all possible 
parameters, REMOTEUSER tdiich provides remote user-specific info, 
LOCALUSER vAich provides local user-specific info, EERiCa?S vAiich 
provides general error help, a set of Exxxx topics for specific 
errors viiere xxxx is a specific error code (the text will discuss 
jxjssible corrections, not just reiterate the original error message 
text), EXAMPLE which gives an exanqple of a file/mail transfer, and 
MINIMAL v*iich describes the minimal set of commands suid parameters 
to do a rudimentary mail transfer. There will also be at least one 
topic for eeush command and each parameter, plus topics on general 
subjects such as record structures, character sets, examples, etc. 

g. NOOP CXMIAND (RFC-821, pg 26) 

This command shall not affect any parameters or previously entered 
\J) cammands and the only action to be taken is that the receiver of \jl 

this ccanmand shall send an CSf reply. 

1. CXDMiAND PCM1AT - NOOP[SP] [CRLF] (RFC-821, pg 29) 

NOOP - The ccMnmand code shall be the character string "NOOP" in 
tjpper and/or lower case ASCII characters. (RFC-821, pg 26,27) 

EXAMPLE - NOOP 

h. ^JIT CO-MAND (RFC-821, pg 26) 

This ccanmand shall be sent by the sender SMTP and shall cause the 
reciver SMTP to send an CSi reply and then close the transmission 
channel . 

o o 
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(Q) 1. COMMAND FORMAT - QUIT[SP] [C3iLF] (Rrc-821, pg 29) O 

QUIT - The command code shall be the character string "QUIT" in 
vipper and/or lower case ASCII characters, (RPC-821, pg 26,27) 

EXAMPLE - RSET 
3.7.2.2 SMTP Replies {RFC-821, pg 34) 

Replies to smP commands shall be used to ensure the synchronization of 
requests and actions in the process of mail transfer, and to guarantee that 
the sende^-S^frP always knows the state of the receiver-SMTP. 

NOTE: In the following paragraphs [SP] means an ASCII space and [CRLF] 
means an ASCII Carriage Return Line feed. 

a. At least one reply shall be generated by the receiver SMTP for each 

^ J command received. (RFC-821, pg 34) yy 

b. A single line SMTP reply shall consist of a 3 digit code transmitted 
as three alphanumeric characters followed by a [SP] , followed by one 
line of text, followed by a [CRLF] . (RFC-821, pg 34) 

c. Multi line replies shall consist of a three digit code, followed 
immediately by a Hyphen "-", also known as a minus sign, followed by 
text. The last line shall begin with the same three digit code, 
followed by a [SP] , some optional text, and terminated by a [CRLF]. 
(RFC-821, pg 50) 
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(3 3.7.2.2.1 SMTP Reply Codes (RFC-821, pg 48) 



o 



The SMTP reply codes and their meaning sheill be as shown below: 

a. The first digit, most significant, of the reply code shall have one 
of the following values: {RFC-821, pg 48) 

1. Ixx - Positive preliminary reply (RFC-821, pg 48) 

The SMTP does not have any ccMnmands that would edlow this reply 
and it shall not be implemented. 

2. 2xx - Positive completion reply {RFC-821, pg 48) 



o 



The requested action has been successfully ccwipleted and a new 
ccanmand may be initiated. 

3. 3xx - Positive intermediate reply {RFC-821, pg 48) 



o 



The ccramand has been accepted and the requested action is being 
held in abeyance pending receipt of another ccamnand from the 
sender SMTP specifies the required information. 

4. 4xx - Transient negative completion reply {RPC-821, pg 48) 

The ccannand has not been accepted and requested action did not 
take place. The error condition is tonporary and the sender 
SMTP should reissue the command or return to the beginning of 
the command sequence. 

5. 5xx - Permanent negative completion reply {RPC-821, pg 49) 



O 



The command has not been accepted and the requrested action did 
not take place. The sender SMTP should not repeat the exact 
consnand or command sequence. 



o 
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b. The second digit of the reply code shall indicate specific 
fvmctional categories with one of the following values: (RFU-821, 
pg 49) 

1. xOx - Syntax error {RFC-821, pg 49) 

These replies refer to syntactically correct commands that don't 
fit any functional category, are unimplranented or superf luoiis . 

2. xlx - Information {RFC-821, pg 49) 

These replies are for requests for information such as status or 
help. 

3. x2x - Connections (RFC-821, pg 49) 

^ ^ These are replies referring to the transmission channel. ^ n^ 

4. x3x - IMspecified (RFC-821, pg 49) 

5. x4x - Unspecified (RFC-821, pg 49) 

6. x5x - Mail system (RPC-821, pg 49) 

These replies indicate the status of the receiver mail system 
relative to the requested transfer or other mail system action. 

c. The third digit, least significant, shall give a more precise 
meaning to each of the function categories specified by the first 
and second digit defined in above subsections a. and b. While the 
text in the following listed replies is only suggested, the first 
aiKi second digit shown are mandatory and shall not be changed. 
(RFC-821, pg 49) 



%./ 



(6444WAT35) OCWTROL DATA PRIVATE 3-156 



HKSYSIM-OOa-ERS-OO-C 
10 December 1986 

f^. 1. 211 System statvis, or system help ready (RFC-821, pg 36) f^ 

2. 214 Help message (RFC-821, pg 36) (Information on how to use the 
receiver or the meeining of a particular non-staxidard command. ) 

3. 220 (dcMuain) Service ready (RFX>821, pg 36) (Where domain is the 
name of host receiving host) 

4. 221 (domain) Service closing transmission channel (RFC-821, 
pg 36) 

5. 250 Requested mail action okay and completed (RFC-821, pg 36) 

6. 251 User not local, will forward to (forward-iiath) (Rrc-821, 
pg 36) (Where forward-path is host name.) 

7. 354 Start mail input, end with [CRLF] . [CRLF] (RPC-821, pg 36) 

o o 

8. 421 (domain) Service not a\'ailable, closing transmission channel 
(RFC-821, pg 36) (This may be a reply to any command if the 
service knows it must shut down. ) 

9. 450 Requested mail action not taken, mailbox unavailable 
(RFC-821, pg 36) (For example, the mailbox may be busy.) 

10. 451 Requested action aborted, local error in processing 
(RPC-821, pg 36) 

11. 452 Requested action not taken, insufficient systan storage 
(RPC-821, pg 36) 

12. 500 Syntax error, cranraand unrecognized (RFC-821, pg 36) (This 
may include errors such eis command line too long.) 

o o 
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\J 13. 501 Syntax error in parameters or arguments (RFC-821, pg 36) \J^ 

14. 502 Conmand not implemented (RFX3-821, pg 36) 

15. 503 Bad sequence of commands {RPC-821, pg 36) 

16. 504 Command parameter not implemented (RPC-821, pg 36) 

17. 550 Requested action not taken, mailbox unavailable {RPC-821, 
pg 36) (For example, mailbox not found, no access.) 

18. 551 User not local, please try (forward-path) (RPC-821, pg 36) 

19. 552 Requested mail action aborted, exceeded storage allocation 
(RPC-821, pg 36) 



\ 



20. 553 Requested action not taken, mailbox name not allowed 
\J (RPC-821, pg 36) (For example, mailbox syntax incorrect.) 

21. 554 Transaction failed (RPC-821, pg 36) 

3.7.2.2.2 Sequencing of Coranands and Replies (RFC-821, i« 37) 

The ccanmunication between the sender and the receiver shall be an alternating 
dialog implonented as follows. 

a. "Hie sender shall issue cranmands to the receiver and wait for a reply 
before sending further commands. (RPC-821, pg 37) 

b. The receiver shall send one reply to the sender for each received 
commmand. (RFC-821, pg 37) 



■^y 
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r^) c. The specific CO'IMAND-REPLY sequences shall be as below (RFC-821, pg. f"j 
37): 

hKXTE: In subsections 1 through 15 below each coinmand is listed and 

is followed by possible reply codes prefixed with "S" for 

success, "E" for error, "I" for intermediate, and "F" for 
failure. 

1. Connection Establishment (RFC-821, pg 37) 

S: 220 
F: 421 

2. HELD (RFC-821, pg 37) 

S: 250 

E: 500, 501, 504, 421 

o ■ o 

3. MAIL (RFC-821, pg 37) 

S: 250 

F: 552, 451, 452 

E: 500, 501, 421 

4. RCPT (RFC-821, pg 38) 

S: 250, 251 

F: 550, 551, 552, 553, 450, 451, 452 

E: 500, 501, 503, 421 

5. DATA (RPC-821, pg 38) 

I: 354 (followed by data, then) 
S: 250 
O) F: 552, 554, 451, 452 ^ 
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O F: 451. 554 O 



F: 451, 554 
E: 500, 501, 503, 421 

6. RSET (RFC-821, pg 38) 

S: 250 

E: 500, 501, 504, 421 

7. SEND (RFC-821, pg 38) 

E: 502 (This command not implemented) 

8. SGML (RFC-821, pg 38) 

E: 502 (This command not implemented) 

9. SAML (RFC-821, pg 38) 

E: 502 (This command not implemented) 

10. \KFY (RFC-821, pg 38) 

E: 502 (This command not implemented) 

11. EXFN (RPC-821, pg 38) 

E: 502 (This ccMnmand not implemented) 

12. HELP {RFC-821, pg 38) 

S: 211, 214 

E: 500, 501, 502, 504, 421 






o o 
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._^ 



13. NOOP (RPC-821, pg 38) ^) 



S: 250 

E: 500, 421 

14. QMET (RFC-821, pg 38) 

S: 221 
E: 500 

15. TURN (RFC-821, pg 38) 

F: 502 Cniis conanand not implemented) 

3.7.2.3 Transparency (RFC-821, pg 41) 

To edlow all iiser ccMnposed text to be transmitted transparently the following 
■ j) procedures shall be implemented. mj) 

a. Before sending a line of mail text the sender SMTP shall check the 
first character of the line for a period and, if found, shsdl insert 
one additional period at the beginning of the line. (RFC-821, 
pg 41) 

b. V?hen a line of mail text is received by the receiver SMTP, the 
receiver SMTP shall check the first character of the line for a 
period. If the first character is a period and there are no other 
characters in the line, then the receiver SMTP shall interpret the 
line as the end of mail. If the line contains additional 
characters, the receiver SMTP shall delete the first character 
(period) and interpret the line as mail data. (RFC-821, pg 41) 



On 
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\J 3.7.2.4 Sizes {RPC-821, pg 42) \J 

The SMTP implementation shall be able to receive objects of at least the 
following sizes and shall not send objects larger than the following sizes. 
(RPC-821, pg 42) 

a. USER NAME {RFC-821, pg 42) 

The maximum total length of the liser name shall be 64 characters. 

b. DOMAIN (EEX:-821, pg 42) 

The maximton total length of a dcanain name or number shall be 64 
characters . 

c. PATH (RFC-821, pg 42) 



-■'' ^\ 



V y '^® maximum total length of a reverse-path or forward-jjath shall be '-^...J 

256 characters, including punctuation and element separators. 

d. OC»MAND LINE (RFC-821, pg 42) 

The maximiOTi total length of a command line, including the command 
word and the [CRLF] , shall be 512 characters. 

e. REPLY LINE (RPC-821, pg 42) 

The maximum total length of a reply line, inclixiing the reply code 
and the [CRLF], shall be 512 characters. 

f. TEXT LINE (RPC-821, pg 43) 

The maximum total length of a text line, including the [CRLF] but 
not including the duplicated period, shall be 1000 characters. 

o. . c 
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g. RECIPIENTS BUFFER (RPC-821, pg 43) 



o 



The maximum total number of recipients that must be buffered shall 
be 100. 

3.7.3 External Interfaces (RPC-821) 

The following subsections define the SMTP external interfaces. Interfaces 
are provided for direct user call of S^^^P and for application calls to SMTP. 



£^i 



3.7.3.1 Application Program (RFC-821) 

The Application Program interface shall be provided by SMTP to application 
programs written in FORTRAN or any language that can interface to PCSITRAN 
(for example, SYMPL, CYBIL, COBOL). The SMTP Control Statement interface and 
the local host mail server shall use this interface to euxsess the SMTP 
capabilities. In the following discussions, the term 'standard_character' 
string is \jsed to refer to a FORTRAN character string or to an array of 
60-bit words that contains left- justified chsui^icters, zero-filled and 
zero-byte terminated, A standard_character string uses the 6/12 display code 
representation, so the display code escape chareu^ter will always be 
interpreted as such. If a standard_character string can contain n characters 
then the calling routine should allocate 2n 6-bit bytes (10 bytes per 60-bit 
word) for the worst case of all lower cause characters. The term 
*najiie_character* is used to refer to the character subset consisting of 
alphabetic (A-Z), numeric (0-9), minus sign (-), and period (.) characters. 

3.7.3.1.1 SNrrP_Accept_Mail (SMTPAM) Routine (RFC-821) 

The SMTP Accept_Mail routine shall return to the application program a mail 
message received by SMTP. This function is used by local host mail servers 
to get S^f^P mail amd route it to the local host user. Only applications 



o 
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that have connected to SMTP via the SMrP_Connect_Server routine may use this 
routine. The calling format shall be: 



o 



CALL SMTPAM (message_size , message, nojwait, reply_code, more_data) 



message size 



Maximum number of 6-bit characters to be placed in 
the buffer. An integer number supplied by the 
application. 



message 



Buffer to receive the mail message. A 
standard_character string returned by SMTP containing 
up to message_size chareicters. The mail source 
( reverse jpath) and mail destination (forward_path) 
can be obtained by the ai>plication from the message 
header. 



no wait 



Indicates no waiting for cranpletion. Boolean value 
supplied by application. If true, the routine will 
return imnediately if no mail messages have arrived 
for processing. The application roust then call 
SMrP_Accept_Mail again later to check again. If 
no_wait is supplied, it is important that the 
application check frequently or mail messages may be 
lost. If no_wait is false, the application is rolled 
out until a message arrives. 



v.. 



reply_code 



Reply code frcan request. Integer value is returned 
by SMTP for completed requests regardless of 
success. Reply codes are defined in section 
3.7.2.2.1. Reply code is zero or negative if no_wait 
is specified and no mail messages are available. 



o 
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morejdata Indicates that the message buffer was not large \^ 

enough to contain the entire mail message. Boolean 
value returned by SMTP. If true, a subsequent call 
to 91TP_Acc^t_Mail will return the next buffer of 
the message. When the end of the message is 
encountered (morejdata false), a s^bsec^ent call to 
SMTP_ Accept_Mail will return the data from the next 
mail rr^ssage. 

3.7.3.1.2 SMTP„AccqDt__Rq3ly (SMTPAR) Routine (RFC-821) 

The SMTP Acc^t_Reply routine shall return the response to the last request 
issued. This routine can also be used to wait for oonnpletion of requests 
that were previously issued with no_wait. The calling format shall be: 

C^^_L SMTPAR (reply, no_wait, reply_code, morejdata) 

%^ reply Textual r^ly from last SMTP request. A standard ^Jj) 

character string returned by SMTP containing up to 
80 characters of r^ly text. The text for replies 
from a local CYBER SMTP is specified in section 
3.7.2.2. This value is the string "Response 
pending," if r^ly._code is zero. 

noj*jait Indicates no waiting for conrpletion. Boolean value 

supplied by ^aplication. If true, the routine will 
return immediately if the previous request has not 
completed. The application must then call SMTP 
AccqDt..R^ly again later to determine the r^ly. 



O O 
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reply_code 



Reply code from previous request. Integer value is 
returned by SMTP for completed requests regardless 
of success. Reply codes Eire defined in section 
3.7.2.2.1. Reply code is zero or negative if 
no_wait is specified and operation is currently in 
progress. 



o 



more data 



Indicates the reply text is continued on another 
line (80 character array). Boolean value returned 
by SMTP. If true, a subsequent call to 
S>nP_Accept_Reply will return the next line of the 
message. When the Isist line is read (more_reply 
false), a subsequent call to SMrP_Accept_Reply will 
return the last line of the response. 



3,7.3.1.3 SmP_Connect (SMTPC) Routine (RPC-821) 



The S!^rP_Connect routine shall request the SMTP Protocol Interpreter to 
establish a connection with an SMTP residing on a remote host. An 
application may have only one SMTP connection established at once. The 
calling format shall be: 



V.^^' 



CALL SMTPC {reply_code) 

reply_code Reply from connection atten^Jt. Integer value is returned 
by S^frP for all connection attaiqpts regardless of success. 
Reply codes are defined in section 3.7.2.2.1. If the 
application requires the message text, the 
S?TrP_Accept_Reply routine must be called. 

3.7.3.1.4 S^nP_Connect_Server (SMTPCS) Routine {RFC-821) 



The S^f^P_Connect_Serve^ routine shall request the SMTP Protocol Interpreter 
to send messages received that are destined for the local host. An 
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\.y application may have only one SMTP connection established at once, . but many \y 

independent servers may be connected simultaneously; in this case, a server 
is assigned to an available message if it is non-bvisy. The calling format 
shall be: 

CALL SMTPCS {reply_code) 

reply_code Reply from connection attempt. Integer value is 

returned by SMTP for all connection attempts 
regardless of success. Reply codes are defined in 
section 3.7.2.2.1. If the application requires the 
message text, the SMrP_AcceptJReply routine must be 
called. 

3.7.3.1.5 SMrP_Disconnect (FTPD) Routine (RFC-821) 

^.^^ The SMrP_Disconnect routine shall request the SMTP Protocol Interpreter to ^..^ 
V-/ terminate a previously established connection. The calling format shall be: \y 

CALL StflPD {reply_code) 

reply_code Reply from disconnect attempt. Integer vadve is 

returned by SMTP for all attonpts r^gsirdless of 
success. Reply codes are defined in section 
3.7.2.2.1. If the application requires the message 
text, the SMrP_Accept_Reply routine must be called. 

3.7.3.1.6 SMrP_Mail_C<MHiiand (SMTPMC) Routine (RFC-821) 

The S^f^P_Mail_Cc»ranand routine shall request the SMTP protocol interpreter to 
process a command, that is not directly supported by other S^f^P calls. The 
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O ~^ «.P. «X=P, ^. ^ RSCT. as ^ifisd in s^tion 3.7.2.1.5.1. a^ 

sent using this procedure. The calling format shall be: 



o 



CALL SMTPtiC (command, no_wait, r^ly_code) 



command 



SMTP command to be issued. A standard_character 
string supplied by the application containing up to 
512 characters. ShfTP maintains state tables and will 
reject any command issued that is inappropriate for 
the current state, or for improperly formatted 
commands. 



no wait 



rqolyjDode 



Indicates no waiting for completion. Boolean value 
supplied by application. If true, the routine will 
return immediately after issuing the request. The 
application must then call SMTP_Accept_Reply to 
subsequently determine the reply. 

Reply from command reediest. Integer value is 
returned by SMTP for all attempts regardless of 
success. R^ly codes are defined in section 
3.7.2.2.1. If the application requires the message 
text, the SMTP_Accept_R^ly routine must be called. 
Reply code is zero or negative if no_wait is 
specified and operation is currently in progress. 



V, 



3.7.3.1.7 SMTP_MailJ)ata (SMTPMD) Routine (RFC-821) 

The SMTPJ1ail_pata routine shall rec^est the SMTP protocol interpreter to 
send a message to the recipient previously specified in SMTPMR calls. The 
calling format shall be: 



o 



CALL SMTPMD Cmessage_si2e, message, no_wait, rq3ly_pocle) 
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Number of 6-bit characters in the message buffer. 



o 



message 



Messeige data to be sent to previously defined 
recipients. A standard_character string supplied by 
the aj^lication containing any number of characters 
with no more than 1000 chairacters per line. 



no wait 



Indicates no waiting for completion. Boolean value 
supplied by application. If true, the routine will 
retvim immediately after issuing the request. The 
application must then call SMrP_Accept_Reply to 
subsequently determine the reply. 



o 



reply_code Reply from command request. Integer value is 

returned by S^f^P for all attempts regardless of 
sviccess. Reply codes are defined in section 
3.7.2.2.1. If the application requires the message 
text, the SI^rP_Accept_Reply routine must be called. 
Reply code is zero or negative if no_wait is 
specified and operation is currently in progress. 

3.7.3.1.8 a^rP_Mail_File (EMTFMF) Routine {RPC-821) 

The SMrP_Mail_File routine sheill request the S^f^P protocol interpreter to 
send the contents of a file as a mail message to the recipients specified in 
previous SMIWE calls. The calling format shall be: 

CALL SMTFMF (file_name, file_access, no_wait, reply_code) 



o 



o 



file name 



Name of file containing data to be sent to previously 
defined recipients. A display code string supplied 
by the application containing up to 7 chai^usters. If 
the file is not local to the job, or if 
file_parameters is specfied, SMTP protocol 
interpreter will attempt to acquire a permanent file 
by that name. 



o 
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f i le_parameters 



Permanent file access parameters. A display code 
string supplied by the application containing ijp to 
80 characters of file access directives. Hie 
directives are identical to those supplied for NOS 
permanent file control statement requests (for 
example, Rv'=packname, UN=usemame) and should follow 
the same syntax. Both direct and indirect access 
files can be referenced; it is not necessary to 
specify vdiich kind the file is. If parameter is 
zero, an empty string, or a blank string then the 
current default parameters for the local job are 
used, and a local file is accessed if present. 



o 



no wait 



Indicates no waiting for completion. Boolean value 
supplied by application. If true, the routine will 
return immediately after issuing the request. The 
application must then call SMrP_Accept_Reply to 
subsequently determine the reply. 



J 



reply_code 



Reply frcan ccanmand request. Integer value is 
returned by SMTP for all attempts regardless of 
success. Reply codes are defined in section 
3.7.2.2.1. If the application requires the message 
text, the SMTP_Accept_Reply routine must be called. 
Reply code is zero or negative if no wait is 
specified and operation is currently in progress. 



3.7.3.1.9 SMrP_Mail_Header (SMTPMH) Routine (RPC-B21) 

The SMrP_Mail_Header routine shall insert the requested Mail text header 
fields into a Mail header buffer to be sent later with a mail message. This 
routine permits an application to use other fields defined by the ARPANET 
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Intertext Mail Standard that are not directly maintained by SMTP. The /^ 
calling format shall be: . 

CALL SMTPMH (header_field, no_Kait, reply_code) 

header_field A mail header field consisting of a field-name and a 

field-body. A standard_character string containing 
up to 1000 characters. The field name can be any of 
the standard fields except 'data*, 'from', 'to', and 
*cc' vAiich are all maintained directly by SMTP. Both 
the field-name and field-body are checked for 
adherance to the standard. If SMrP_Mail_Header is 
called more than once for a given field-name, the 
field-name will be entered only once in the message 
header with subsequent field-body entries following 
the first at the same indentation level . 

/^ no_wait Indicates no waiting for completion. Boolean value ^\ 

sufjplied by application. If true, the routine will 
retvjm insnediately after issuing the request. The 
application must then call SMrP_Accept_Reply to 
subsequently determine the reply. 

reply_code Reply frcan ccsnmand request. Integer value is 

returned by SMTP for all attsnpts regardless of 
six2cess. Reply codes are defined in section 
3.7.2.2.1. If the application requires the message 
text, the SMTP_Accept_Reply routine must be called. 
Reply code is zero or negative if nojwait is 
specified and operation is currently in progress. 

3.7.3.1.10 SMTPJIailJRecipient (SMTFMR) Routine (RFC-821) 

The SMTP_Mail_Recipient routine shall identify a mail recipient for a 
#\ subsequent message to be sent vising the SMTP MD/SWTFMF requests. The calling ^ f% 
format shsill be: . 
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CALL SMITMR (distribution_class, forwardjpath, nojwait, reply_cxxie) 



o 



distribution_class Distribution class of the recipient. A 

standard_character string supplied by the 
application containing either the string 'CX:!',"TO', 
or 'BCC'. If 'CC' is supplied, the recipient 
forward_path is listed in the 'CT:' portion of the 



message header . 



If 



'TO' 



is supplied, the 



forward_path is listed in the *T0:* portion of the 

message header. If 'BOC' is supplied, the 

forward_jjath is listed in the 'BOC' portion of the 
message header. 



forward_path 



v.y' 



no wait 



Forward path of recipient. A standard_character 
string supplied by the application containing up to 
256 characters. 

Indicates no waiting for ccanpletion. Boolean value 
supplied by application. If true, the routine will 
return immediately after issuing the request. The 
application must then call S^f^P_Accept_Reply to 
subsequently determine the reply. 






reply_code 



Reply fran ccsmnand request. Integer value is 
returned by SMTP for all atten5)ts regardless of 
success. Reply codes are defined in section 
3.7.2.2.1. If the application requires the message 
text, the SMrP_Accept_Reply routine must be called. 
Reply code is zero or negative if no_wait is 
specified and operation is currently in progress. 



o 
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3.7.3.2 User Control Statement (RFC-821) 



o 



"The Cksntrol Statement interface shall be provided by SMTP to terminal user 
Jobs, batch jobs, and CYBER Control Language (CCL) procedures. If the 
control statanent is invoked frc«n a terminal, the program shall perform a 
dialogue with the user, displaying replies as they are received and sending 
commands as they are entered. All parameters Eu:e order- independent. The 
format of the control statement shall be: 

SMTP {I=ccMiimand_file, L=output_f ile , NA, PC=prefix_char) 



command file 



o 



Name of local file containing SMTP commaiKls. If 
emitted, file INPUT is assumed. If the file is 
Eissigned to a terminal, SMTP may perform an 
intei-active dialogue with the user, depending on the 
output_file. If 1=0, SMTP will take ccMiimands frcan 
subsequent lines of the current control statement 
file. SMTP ccmmands are distinguished frcan control 
statements by the prefix character specif ied by the 
PC parameter. The prefix character is not required 
for commands in any file except the control statonent 
file. 



o 



output_file 



Name of file to receive SMTP messages. These 
messages consist of canmand replies frcan the SMTP 
protocol interpreter. If the file is assigned to a 
terminal and cc»nmand_file is also assigned to a 
terminal, then SMTP will perform an interactive 
dialogue with the tiser. If L=0, output messages are 
discarded. 



o 
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'\J NA No-abort parameter. If specified, SMTP will continue \J 

to read and process commands even if errors are 
encountered; normally, SMTP will abort the user if 
errors are encountered in a conmand file that is not 
assigned to a terminal. TTiis parameter has no 
mesming for interactive users. 

prefix_char Command prefix character. This character must 

precede all commands which are embedded in the 

control statenent file (in other words, if 3^0) 

following the SMTP statement. If emitted, asterisk 
{») is assumed. 

The following command allows the user to specify header-fields in a message 
header. 

INFO[SP] [HEADER-FIELD] where: 

HEADER-FIELD is a legal header-field as defined by the ARPANET 
Internet Text Message standard. All field names are permitted 
except DATE, FROM, TO, and OC which are maintained by SMTP. 

The Receipt (IKFT) command has been extended to permit the string 'CC: * 
instead of the 'TO:' string. If supplied, SMTP will enter the forward-path 
in the CC field of the message header. Normally, it is entered in the TO 
field. 

3.7.3.3 DDN/C170 Application Interface {RPC-821) 

SIfEP shall utilize the DDN/C170 Application Interface to access DDN. Section 
3.8.3 defines the DDN/C170 Application Interface primitives. The following 
services of the Application Interface shall be used: 



o ■ ' o 
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1) TCP Primitives (RFC-821) 

2) Host name server translation and error reporting (RFC-821) 

3) DDN error logging (RFC-821) 

3.7.3.4 SMTP Peer Protocol (RPC-821) 

SMTP shall implement the communicate with remote SMTP processes using the 
peer protocol specified in section 3.7.2. 

3.7.3.5 Network Definition File (RFC-821) 

SMTP shall define its NAM application parameters via NDL configuration 
directives. "Hie directives used are defined in section 3.7.8. 

3.6.3.6 Operator Interface 

SMTP shall sdlow the operator to exercise some control over vdiich messafes ae 
([^ written to the log file. "Hie following are the K-display HOP commands used to Cj) 
control message wiring to the log file. 

K.DE = SMTP Write error messages only to the log file 
K.DB = SMTP Write debug and error messages to the log file 
K.RS = ShflP Write statistics, debug, and error messages to the log 
file 

Error messages are always written to the log file regardless of any operator 
intervention. 

If the application has been loaded using NETIQD, the K.RS ccanmand will also 
restart AIP statistical gathering. 



o o 
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Q) 3.7.4 Internal Interfaces (RPC-821) (f~J) 

The following subsection describe the interfaces between the major components 
of CYBER SMTP. The internal interfaces identified are: 

Control Statement to Application Interface 

3.7.4.1 Control Statement to Application Interface (RPC-821) 

The Control Statement to Application Interface is implemented by the AI 

routines. Ihese routines are used by SMTP C/S to issue SMTP requests on 

behalf of an interactive terminal user or NOS batch job. This interface is 
defined in subsection 3.7.3.1. 

3.7.5 Errors and Error Recovery (RPO-821) 

3.7.5.1 Size Errors (RFC-821, pg 43) 

/""\ -" x^~\ 

The following error reply codes shall be used for errors in object size 
specified in 3.7.2.4a thru 3.7.2.4g. 

a. 500 - line too long (RFC-821, pg 43) 

b. 501 - path too long (RFC-821, pg 43) 

c. 552 - too many recipients (RFC-821, pg 43) 

d. 552 - too much mail data (RFC-821, pg 43) 



a 
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3.7.6 Data Structures 



v./ 



Mail data shall conform to RPC-822, Standard for ARPA Internet Text 
Messages. (RFC-821, pg 5) 

NOTE: In the following subsections, references are made to formal 
definitions of syntax contained in RFC-822. These references, 
although correct, will not provide the total definition of all 
syntactical entities and the reader, reviewer, developer, tester, etc. 
is referenced to Appendix L vdiich is an extension of this ERS section 
3.7. Appendix L contains the ccmplete and formal syntax definitions 
for SMTP as reproduced frran RFX>822. In the event of conflict between 
this ERS and the formal syntax described in Appendix L, Appendix L 
shall be the document of precedence. 

Appendix L - Pages 3, 4, 9, 10, 11, 17, 18, 19, 26, 27, 44 through 47. 

(J 3.7.6.1 ARPA Internet Text Messages (RFC-822, pg 1) ^ 

The ARPA Internet Text Message Standard specifies the syntax for text 
messages sent among computer lasers within the framework of electronic mail. 
It defines a message as consisting of scane information in a rigidly defined 
format followed by additional information in an unspecified format. 

The rigidly defined portion of a message is referred to as a header field 
vdiich consists of a field name aixJ a field body. The field name consists of 
ASCII characters and is separated f rem the field body by a colon " : " . Field 
bodies are of two types, termed structured field bodies and unstructured 
field bodies, with the difference being that structured field bodies are 
defined by a formal syntax, and unstructured field bodies consist of simply 
text. 
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i 1^ "^^ information in the message without a specified format is the main part of (Oi 
the message and can be thought of as the message body. The message body 
consists of all text fran the null line after the last header field to the 
end of mail indicator vdiich is a line containing only a period as the first 
and only character. 

Figure 3.7-3, SMTP Implemented Message Standard, illustrates the above 
discussion and the requirements for implementation as stated in subsection 
3.7.6.1.1 below. 

The figure is to be interpreted as being read from the top: Message to 
Header-Field and then Field-Name and/or Field-Body, then from the top to the 
right vdien a Null-Line is detected and dovm to Message-Body. 

Following the above interpretation, the figure illustrates that a mail 
Message consists of a Header-Field viiich contains a Field-Name and Field-Body 
made up of Structured-Fields and IMstructured-Fields vAiich is followed by 
'^"^j information contained in the mail Message-Body. f" ^ 



O 
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Message 



Header-Field 



Field-Name 






Stimctured-Field 



-Rettim-path : 

-Received: 

-Date: 

-From: 

-To: 

-cc: 

-Subject: 

-CkDnments: 
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Null-Line [CRLF] 



Ifessage-Bcdy 
I 

!-«te5ct 



Field-Body 



IMstructured-Field 



-route-addr 

-"frcan" dcanain ";" date-time 

-date- time 

-mailbox 

-l#address 

-Ifaddress 



o 



-*text 
-*text 



Figure 3.7-3. SMTP Implanented Message Standard 



o 
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\-J With all of the above in mind, the following is an example of a mail Message ^^ 

that would follow the DATA COMMAND in 3. 7. 2. 1.5. Id: 

Date: 20 Jan 85 09:00:00 

From: R J Yvmia <rjyuma@CDCNOS . SSDF> 

Subject: Preliminary Design Review 

To: rjschal@CDCNOS.SSDF 

[CRLF] this is null line 

Ron: 

The DDN PDR is scheduled for 29 Jan 85. Please be prepared. 
Russ 

this terminates the roessEige body 

3.7.6.1.1 Header Field Definitions (RFC-822, pg 9) 

a. The formal definition of HEADER FIELDS shall be as shown on page 9 

. , of RFC-822. (RFC-822, pg 9) ^ ^ 

b. nie header field shall consist of a field-name followed by a colon 
":", followed by a field-body and terminated by a carriage 
return/line feed. (RFC-822, pg 6) 

c. The field-name shall be conqxDsed of printable ASCII characters with 
decimal values between 33 and 126, except for the colon ":", decimal 
value 58. (RFt;-822, pg 6) 

d. The field-body shall be composed of a structured field-body or an 
unstructured field-body as defined below. (RFC-822, pg 6) 

1. Structured field bodj' (RFC-822, pg 6) 

Any field-body that is defined as other than simple text shall 
be processed as a structured field according to an internal 
^^ syntax. (RFC-822, pg 6) ^-^ 

G O 
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2. Unstructixred field body (RPC-822, pg 6) 



■^ 



Any field-body composed of simply text shall be defined as 
unstructxired and processed as a string of text. (RFC-822, pg 6) 

e. The field-names that shall be implemented are shown below. 
(RFC-821, pg. 20 

1. Return-path: (RFC-822, pg 20) 

The structiared field-body for this field-name shall be added by 
the receiving SMTP that delivers the message to its recipient. 
TtiB field is intended to contain definitive information about 
the eiddress and route back to the message's originator. 

2. Received: (RFC-822, pg 20) 

\J^ The structured field-body for this field-name shall be added by Vi^ 

the receiving SMTP that accepts a mail message for delivery to 
its recipient. 

3. Date: (RFC-822, pg 17,18) 

The structured field-body for this field-name shall be added by 
the sending SbfTP and shall contain the date and time that the 
mess£ige was sent. 

4. From: (RFC-822, pg 21) 

The structured field-body for this field-name shall be created 

by the sending SMTP. It shall contain an authenticated machine 

address that is machine usable that indicates the person, 

system, or process creating the messsige and it shall not contain 
_^ lists. ^^ 

o o 
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5. To: (RFC-822, pg 23) 

The structured field-body for this field-name shall contain the 
identity of the primary recipients of the message and shall be 
generated by the sender SMTP. 

NOTE: The sender SMTP shall allow "Postmaster" in upper and/or 
lower case as a legal part of the local part of a mailbox 
(see note in f4 below). (RPC-822, pg 33) 

6. C3C: (RFC-822, pg 23) 

The structured field-body for this field-namd shall contain the 
identity of the secondary recipients of the message and shall be 
generated by the sender S>rrP. 

7. Subject: (RFC-822, pg 24) 

The unstructured field-body for this field-name is intended to 
provide a summary or indicate the nature of the message and 
shall be generated by the sender SMTP. 

8. Comments: (RFC-822, pg 24) 

The unstructxared field-body for this field-name is intended to 
allow adding conments onto the message without disturbing the 
contents of the messeige body and shall be generated by the 
sender S>rrP. 

f . The corresponding field-bodies for the above field-names shall be as 
shown below. (RFC-822, pg. 17) 

1. route-addr (Rrc-822, pg 17) 

o _ o 
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O 2. "from" domain "by" domain ";" date-time (RPC-822, pg 17) O 

3. date-time (RFC-822, pg 18) 

4. mailbox (RFC-822, pg 18) 

5. l#address (RFC-822, pg 18) 

NOTE: The receiver SMTP sheuLl recognize "Postmaster" as a 
reserved mailbox lAiere "Postniaster" is the local part of 
the address and shall be recognized in either upper 
and/or lower case. Mail sent to this address shall be 
routed to a person responsible for the site's mail 
system. (RPC-822, pg 33) 

6. l#address (RFC-822, pg 18) 

O 7. *text (RFC-822, pg 18) ^ 

8. «text (RFC-822, pg 18) 

3.7.7 Equipntent Ccoifiguraticxi 

SMTP has no sjjecial equipment configuration requirements. 

3.7.8 Installation (RPC-821) 

Hie following subsections define the installation procedures and parameters 
for SMTP. 

3.7.8.1 SMTP Installation Procedure (RFC-821) 

SMTP is installed using the DDNSMTP build procedure and build verification is 
performed using the VDSMTP procedure. SMTP should be treated as a GroiQ) 3 

o o 

(6444W/WP35) OCKTROL DATA PRIVATE 3-183 



o 



HKSYSIM-OOa-ERS-OO-C 
10 December 1986 

job as defined in the NOS Installation Handbook. It depends upon the DDN 
Supervisor Installation defined in subsection 3.8.8. The SMTP product PL is 
maintained in MODIFY format. The following files are created or updated by 
the build procediare: JOBSMTS, HELPLIB( updated), DDNLIB ( updated ) . 

3.7.8.2 SMTP Installation Parameters (RFC-821) 

The following installation parameters can be tailored for specific sites. 
They are located in common deck OCMVIPR. 



O 



IPDIXS Default Local C3iaracter Set. This is the default character set 
for commands, responses and files at the local CYBER host. 
Possible values are ASCII, ASCII8, and DIS as defined by the 
FOOPy statement. The default value is ASCII. 



V 



IPMCTO SMTP COTimand Timeout. Ihis is the maximum time in seconds that 
SmP will wait for a remote SMTP to respond to a ccanraand. After 
this period, the connection will be aborted. The default is 
600. 



\.._ 



IFMBUF Maximum Buffer Size. Ihis is the buffer size used for mail 
transfers. The minimum size is the NAM downline block size (255 
words default). The defaiilt vBdue is 1024B. 



IFMNCP 



SMTP hJOOP Ccanmand Period. This is the jjeriod in seconds at 
which SMTP will issue NOOP commands to a reamote SMTP during wait 
periods to prevent timeout. 



IFRTRY Retry Limit. This is the maximum retry limit for errors before 
SMTP terminates the connection. 



o 
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f ) The following modify symbols can be specified using the *DEFINE directive to 
influence the SMTP build process: 

DEBUG If defined, SMTP will generate AIP trace messages. 

IMS If defined, the SMTP listing will contain Internal Maintainance 
information. 

STATS If defined, SMTP will generate AIP statistics messages. 

3.7.8.3 Network Startup Master File (RFC-821) 

The following directives must be placed in the Network Startup Master File if 
autxMnatic initiation of StfTP is required. 

PARAM(SMrPMS=n) 

Where n is the ntmber of SMTP mail servers to initiate. 

JOB{JOBS^f^s,s^J^s) 



1^^ 



o 



O O 

(6444W/WP35) CXKTROL DATA PRIVATE 3-185 



HKSYSTM-003-ERS-OO-C 
10 December 1986 

3.7.8.4 Network Definition File Directives (RFC-821) 



The following table lists the DDN applications and their configuration 
parameters: 



v.. J 



Number of 
Copies Request 
Name Description (MXCPPYS) Startable Privileged 



SMPI 



SMPS 



SMTP 



SMPA 



SMTP Protocol 


1 


Interpreter 




SMl'P Mail 


1 


Server 




SMi'P Control 


any(5) 


Statement 




SMl'P Mail 


any(l) 


Application 





yes 



no 



no 



no 



yes 



yes 



no 



no 



The values for MXOOPV can be adjusted by the site to control SMTP usage. A 
small number can mean that SMTP users will have to wait for resources viiile a 
large number can tie up TCP and NAM connections and machine resources, 
affecting other users of the system. 



H,. „>' 



Additionally, SMTP application users must provide OUTCALL directives to SMTP 
for their applications. 

3.7.8.5 SmP Transmittal 

No other transmittal can depend upon this transmittal. 



o 



a. SMTP Program Library (SMPnnnn) . This is an UPDATE formatted program 
library containing the S^f^P application interface routines, Protocol 
Interpreter, SMTP Control Statanent. The format of this program 
library is described later. The following object is generated from 
this PL: 
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Name 


Type 


Location 


Description 


SMPI 


Program 


System 


SMi'P Protocol Interpreter 


s^^^p 


Program 


System 


SMi'P Control Statement 


DDNT.TB 


Library 


System 


S>frP Additions to DDN 
Interface Librai-y 


NAMSTRT 


Procedures 


un=NETOPS 


NAM St^rti;?) Proc. Update 
for SMPI (JOBSMPI) 


HELPLIB 


CCL Library 


vin=LIBRARY 


SMTP Help Procedures Update 
to HEIiPLIB 
(SMl'P/SMPPEER) 



b. SMTP Installation procedure (SMTP) 
conventions to install SMTP. 



This procedure follows DECKOPL 



o 



SMTP Installation Verification procedure (VSMTP) . Ihis procedure is 
to be executed on a newly-built system to verify that SMTP has been 
properly installed. It does not verify that SMTP actually works. 
It follows DECKOHi verfication conventions. 



o 



3.7.8.6 PL Structure 

a. Where deck lists eu^e described as 'organized', it means that the 
decks are arranged in a SIMPLE manner logical with the structure of 
the program. For example, the main program followed by all primary 
routines in alphabetical order followed by all minor routines in 
alphabetical order. If no structure can be identified, 'organized' 
degenerates to 'alphabetized', never to 'randcxn' or 'complex'. 



o 



o 
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if 1) b. SMTP PL Structure. (Q 

INFO 

HISTCXIY 

[alphabetized common decks] 

-LIBSYMP- [contains «CWEXa?] 

[SYMPL library routines, alf^mbetized] 

-LIBOQMP- [contains *CWECH] 

[C!C*1PASS librarj' routines, aljiiabetized] 
-SYMPL- [contains *CWEaR] 
-PISYMP- [empty deck] 
[SMPI SYMPL routines, organized] 
-CSSYMP- [empty deck] 
[SMTP CS SYMPL routines, organized] 
-OCWPASS- [contains *CWECR] 
-PICX»1P- [empty deck] 
) [SMPI COMPASS routines, alphabetized] 

-CSC!CMP- [CTipty deck] 

[SMTP CS OCMPASS routines, alp^iabetized] 
-NAMSTOT- [contains *CWECK] 
JOBSMPI 

-HELPLIB- [contains *CWEOR] 
SMTP 

-HECKl- [contains »CWEC»] 
SMPPEER 
-ENDPL- [empty deck] 

NOTE: All non-library SYMPL/(XM>ASS decks are compiled into a large 
library. Tlie SMPI and SMTP main programs are sepsirately loaded 
losing a LIBLOAD frran that library. 






i 



,J 
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DDN System-Wide (defined in DDNTEST) 

CX»IVDDN DDN General Runtime Interface Definitions 

CXDMVDIP DDN System Installation Parameters 

CX:MVFET CIO FET Definitions 

COWFIT CRM FIT Definitions 

CCMVIPC IP Interface Definitions 

OOMVNCT DDN NCT Definitions 

OCMVSYS CYBER System Definitions 

CCMVTCP TCP Interface Definitions 

CCMVTEL TELNET Interface Definitions 



SMTP 



o 



OCMVAPC SMTP Application to Protocol Interpreter Interface 
CCMVIPM SmP Installation Parameters 
CCtNSMP SMTP Definitions 



o 



3.8 DraJ Gtetteway (PEN G/W) 

3.8.1 DBN G/W Abstract 

The purpose of DDN Gateway is to provide general DDN services to CYBER 170 
applications without requiring application knowledge of the CDC3>IET 
in5)lementation of those services. 

The Gateway will provide a DDN Name Server function, a common DDN message 
logging function, and TCP/IP/TELNET primitives and indications. 



O 
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^^-^ 3.8.2 DDN G/W Description V^ 

Figure 3.8-1 depicts the DDN Gateway functional relationships. The gateway 
is divided into three components: 1) The DDN Supervisor, 2) the DDN/C170 
Gateway, and 3) the DDN Application Interface. 

■nie DDN Supervisor provides the Host Name server and message logging 
functions. A NAM application residing in either the 170 or an MDI must 
establish a connection with the Supervisor, Uhidh resides in the 170, and can 
then request DDN Name-to-Address translations or message logging. The name 
translation facility is required by FTP and SMTP to translate DDN dcanain 
names sx^pplied by the user into internet addresses required by TCP/IP. 
CcMinnon message logging is provided so that DDN-specific errors detected by 
independent applications (for exanqsle, FTP, SMTP) are logged in a single 
location for efficient problem analysis and resolution. 



C 



\ 

/ 



The DDN/C170 Gateway provides C170 application access to the TCP/IP/TELNET 
services residing in C3DCNET. A NAM application residing in the 170 
establishes a connection with the DDN/C170 Gateway residing in the CDCNET and 
can then issue TCP/IP/TELNET requests and receive their indications. The 
Gateway is required due to differences in architecture between the 0170 
Network Products used by applications and CDCNET vAiere TCP/IP/TELNET is 
implemented. Primitives and indications are passed over the NAM connection 
between the applications and the Gateway. The Gateway in turn issues the 
primitives to TCP/IP/TELNET, or receives the indications. 

The DDN Application Interface (DDN AI) provides a standard application 
interface to the services provided by DDN Supervisor and DDN/C170 Gateway. 
The AI is a set of routines that can be called by application programs that 
handle the NAM connection and data interfaces required by Supervisor and CI 70 
Gateway. These routines consists of a DDN registration function, a name 
server function, a message logging function, and all the TCP/IP/TELNET 
primitives and indications. 
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The various G/W components communicate via NAM connections that are depicted £°\, 
in Figure 3.8-1 and summarized below: 

1) Application to DDN Supervisor. This connection is initiated and 
terminated by the AI. One connection exists for each instance of 
the Application I/F, vAvich is resident in each application that uses 
DDN services, including SMTP and FTP applications. Any number of 
connections are supported, up to the maximum configured by the 
network administrator. 

2) Ajjplication to DDN/C170 Gateway. The first connection for any given 
NAM application is initiated by the application, v^ile subsequent 
connections can be initiated by either the application or the 
Gateway. Connections can be terminated by either the application or 
the Gateway. One connection exists for each and every TELNET, TCP, 
or IP connection established with an application. 

£^ 3.8.2.1 Gateway Connection Registration ^^ 

A Gateway Connection registration function shall be provided to a CYBER 170 
application that shall provide access to DDN services. DDN ser\'ice access by 
unregistered applications shall be rejected. The registration service shall 
require the user to specify the NAM application name and the type of services 
to be used. The seivice types include direct NAM interface, host protocols 
(for example, TCP/IP/TELNET), or application protocols (for example, 
FTP/SMTP). Any successful registration request shall establish a connection 
with the DDN Supervisor. A successful registration request for host protocol 
services shall establish a connection to the DDN/C170 Gateway. 

A function shall also be provided that allows an application to delete a 
previously established registration. If the registration is deleted, aixy 
outstanding Gateway/RAM connections with the application shall be 
linilaterally terminated. 

o o 
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Figure 3.8-1. DDN Gateway Functional Relationships 
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J 3.8.2.2 DDN Name Translation 



O 



A DDN Domain Name translation function shall be provided by the Gateway CPCI 
to registered CYBER 170 applications. The translation function shsdl accept 
a DDN domain name as defined in RFC-810. If an entry for the name is located 
in the table, an internet address as defined in RPC-923 shall be returned. 
If no entry is found, a condition code sheill be returned. The function shall 
also provide a protocol service verification if requested by the viser. 

The translation function shall use the DDN host name table format as 
specified in RPC-810. 

3.8.2.3 DDN Message Logging 

A DDN Message logging function shall be provided by the Gateway CPCI to 
registered CYBER 170 applications. The logging function shaill Euscept a 
message from an application and shall log the message in a canmon file along 
J^ I) with the time and application name. CB 

3.8.2.4 TELNET Primitives and Indications 

The Gateway CPCI shall provide CDCNET TEUffiT primitive and indication 
services to CYBER 170 application programs. These primitives and indications 
shall be provided as part of the TCP interface in the form of an option 
selecting TELNET protocol translation as specified in the TELNET ERS. 

3.8.2.5 TCP Primitives and Indications 

The Gateway CPCI shall provide CDCNET TCP primitive and indication services 
to CYBER 170 application programs. The services provided shall be identical 
to those specified in the TCP ERS. 
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/T^ If an application issues a TCP open service request, the DDN/C170 Gateway (f 1) 
shall initiate a NAM connection with the application wiiich is used as the 
dedicated data path for that TCP connection. If the TCP connection request 
fails or the connection is terminated, the NAM connection shall be 
terminated. 

If an application has previously issued a successful TCP passive open service 
request, and a TCP connection request indication is received by the DDN/C170 
G/W, the Gateway shall establish a NAM connection with the af^lication. When 
the connection is terminated, or fails, G/W shall terminated the NAM 
connection. 

The DDN/C170 gateway shall maintain a one-to-one correspondence between TCP 
connections and NAM connections, 

3.8.2.6 IP Primitives and Indications 






v_y 



The Gateway CPCI shall provide CDCNET IP primitive and indication services to 
CYBER 170 application programs. The services provided shall be identical to 
those specified in the IP ERS. 

If an application issues an IP open service request, the DDN/C170 Gateway 
shall initiate a NAM connection with the application viiich is used as the 
dedicated data path for that IP connection. If the IP service request fails, 
or the connection is terminated, the NAM connection shall be terminated. 

The DDN/C170 gateway shall maintain a one-to-one correspondence between IP 
service access points and NAM connections. 

3.8.3 External Interfaces 

TTie following subsections define the DDN Gateway CPCI external interfaces. 
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3.8.3.1 Application Program 



The application program interface shall be provided by the Gateway CPCI to 
application programs written in FORTRAN or any langLiage that can interface to 
FCfiTRAN (for example, SYMPL, CYBIL, COBOL). 

3.8.3.1.1 DDN General Service Requests 

The following routines provide general DDN services including registration, 
name translation, and message logging. 

3.8.3.1.1.1 DDN_Register_Application (DDNRA) Routine 



o 



The DDN_Register_Application routine shall register an apiplication with DDN. 
This routine roust be called before any other routine defined in section 
3.8.3.1 can be ijsed. This routine must also be called by any application 
protocol user (for example, user of FTP or SMTP) if that user is also a NAM 
application. 



o 



CALL DDNRA {application_name, NAM_direct_user, number_connections, 
reply) 



application_name 



Name of application. This is the name given to NAM 
and specified in APPL/INCALL/CUTCALL directives in 
the NDL. Upper-case display code string frcwi 1-7 
characters. 
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NAM direct user 



Highest NAM connection groi;qp in use by the 
application. This value must be zero if the 
application does not make direct calls to NAM; this 
value must be specfied if the application does make 
NAM direct calls. DDN will use the next highest 
connection groxjp for its NAM connections. The 
application must take care not to accept or send 
messages over that group. Use of NAM direct access 
with DDN is discouraged. 



c 



number connections 



Integer value: 
support. 



maximum number of connections to 



reply- 



Integer reply code from registration request. 
Possible values Eu:e; 

Application_Registered 

Previously_Registered 

Privileged_Access 

Network Unavailable 



v.. 



3.8.3.1.1.2 DDN_Delete_Registration (DDNDR) Routine 

Ihe DDN_Delete_Registration routine shall delete a previously established 
registration. This routine must be called when an application no longer 
requires DDN services. 

CALL DDNDR ( ) 

3.8.3.1.1.3 DDN_Translate_Naine (DDNTN) Routine 

Hhe DDN_Translate_Name routine shall search for the specified name in the 
host name table and return the associated entry if the name is found. 



c 
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CALL DDNTN (name, required_protocol , entry_type, address_list, 
address_size, name_list, naine_size, system, protocol_list, 
protocol_si2e, canment, comment_size, entry, entryjsize, 
reply, nojwait) 



o 



name 



Name to be translated. A standard_character string 
supplied by the application containing iqs to 24 
characters . 



required_protocol 



o 



entry_type 



Protocol required. This is one of the protocols 
listed in RFX>-810. If the protocol does not appear 
in the protocol list of the entry, an indication 
will be returned. A standard_ch8iracter string 
supplied by the application containing up to 24 
characters. If zero or null, no protocol matching 
is performed. 

Type of entry. A character string returned by G/W 
containing up to 7 cheiracters. Possible \'alues are 
NET, GATEWAY, or HOST. 



o 



address list 



List of internet addresses. An array of character 
strings returned by G/W containing internet 
addresses associated with the name. Each string is 
up to 20 characters long. 



axidress size 



Length of address array. An integer supplied by 
the application specifying the size of the eurray. 
If less space is provided than there are entries, 
the list is truncated. 



name list 



o 



List of alternate names. An array of chareicter 
strings returned by G/W containing alternate names 
associated with the name. Each string is up to 24 
characters long. 



o 
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name size 



Length of name array. An integer supplied by the 

application specifying the size of the array. If 

less space is provided than there are entries, the 
list is truncated. 



c 



system 



protocol_list 



Name of Operating System. A character string 
returned by G/W containing v^) to 24 characters. 

List of supported protocols. An array of character 
strings returned by G/W containing protocols 
supported. Each string is up to 20 chsiracters 
long. 



protocol_size 



..^ 



ccanment 



Length of protocol array. An integer supplied by 
the application specifying the size of the atrray. 
If less space is provided than there are entries, 
the list is truncated. 

Comment string. A standard_character string 
returned by G/W containing the entry comment. 



'^..^' 



comment size 



Length of comment string. An integer supplied by 
the application specifying the size of the comnent 
character string. If the supplied string is 
smaller than the entry string, the string is 
truncated. 



entry 



Full host name table entry. A standard_character 
string returned by G/W containing the exact full 
entry. 



entry_size 



o 



Length of entry string. An integer si^plied by the 
application specifying the size of the entrj^ 
character string. If the supplied string is 
smaller than the entry, the string is truncated. 
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Integer reply code from translation request. 
Possible values are: 

Name_Trans lated 

Protocol_not_Supported 

Appl icat ion_not_Regi stered 



o 



no wait 



Boolean vEdue, if true, routine will return 
immediately after issuing request. The application 
must then call the appropriate accept_indication 
routine (TCPAI, IPAI) to subsequently determine the 
status of the request. 



3.8.3.1.1.4 DDN_Log_Message (DDNm) Routine 



o 



The DDN_Log_Message routine shall pleu^e the specified message in a fcraranon log 
file with the time and application name. 

CALL DDNLM (message, messsige_code , destination, level, source, reply, 
no_wait) 



o 



message 



Message to be logged. An upper-case display code 
character string supplied by the application 
containing t?) to 80 characters and zero_bj^e 
terminated. 



message_code 



Numeric message identifier. An integer in the 
range 0-9999 that uniquely identifies the message 
for this application. 



destination 



o 
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level 



o 



source 



reply 



Integer reply code from logging request, 
values are: 

MessageJLogged 

Privileged_Access 

Application_not_Registered 



Possible 



no_wait Boolean value, if true, will cause routine to return 
immediately after issuing request, with reply set to 
message_logged regardless of the success of log request. 

Error messages are always written to the log file. Debug 
and statistical messaiges are controlled at installation 
time or via operator intervention using the NAM K-display 
HOP commands K.DE, K.DB, and K.RS. 

K.Dl 'activates' error messages only (that is, deactiv-ates 
debug and statistics). K.DB activates error and debug 
('deactivating' statistics), and K.RS activates error, 
debug, and statistics. 



V> 



3.8.3.1.2 TCP Primitives 



3.8.3.1.2.1 TCP_Open_Sap (TCPOS) Routine 



The TCP_Ppen_Sap routine is vised to open a Service Access Point (SAP) with 
the TCP module. It is at this time that the application registers the 



c 
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addresses of its service routines, and receives the addresses of the TCP 
request routines. The format shall be: • 

CALL TCPOS (user__sapid, tcp_sapid, status, no_wait) 



userjsapid 



This is a record that contains the user SAPID and a 
list of user defined routines. The SAPID is an 
integer value whose range is -2**31 to 2**31-1. 



tcp_sapid 



This is the record returned that contains the TCP 
SAPID and a list of the TCP service routines. The 
tcp_sapid is an integer value whose range is -2**31 
to 2**31-1. 



status 



o 



This is the status returned as a result of the open 
rec^est. The following integer values may be 
returned: 

tcp_sap_c^3en 
tcp_sap_unavailable 



o 



no wait 



Boolean value, if true, causes routine to return 
immediately. ^^lication must then call TCPAI to 
subsequently determine results. 



3.8.3.1.2.2 TCP Close__Sap (TCPCS) Routine 

The TCP_Close__Sap routine closes a currently open SAP. All connections 
through the SAP are aborted before the SAP is closed. The calling format 
shall be: 

CPLL TCPCS (tq3._ sapid, status, no^wait) 



o 
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tcp_sapid 



This is the SAPID returned by TCP in the c^oen SAP 
request. It is an integer value whose range is 
-2**31 to 2**31-1. 



status 



This is the status returned as a result of the close 
request. The following integer values may be 
returned: 



tcp_sap_ closi ng 
tcp_sap_not_cpen 



no wait 



Boolean value, if true, causes routine to return 
immediately after issuing request. Application must 
then call TCPAI to subsequently determine results of 
request. 



3.8.3.1.2.3 TCP_Active_Connect (TCPAC) Routines 

The TCP_Active_Connect will attempt to connect to a peer at the specified 
destination. The status of the request will be returned. The calling format 
shall be: 



V.,' 



CALL TCPAC 



(tcp„sapid, userjsepid, tcp_c^id, source, 

destination, allocation, ip_header, ipjsptions, 

ulp_timeout, pushjflag, urgentjflag, data, 

data_length, status, no__wait) 



tcp._sapid 



This is the SAPID returned by TCP in the open SAP 
request. The SAPID is an integer value whose range 
-2**31 to 2**31-1. 



o 
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This is the Connection End Point Identifier (CEPID) 
which will be provided by TCP with all data passed to 
the application. The CEPID is an integer value whose 
range is -2**31 to 2**31-1. 






tcp_c^id 



This is the CEPID created by the TCP that is 
returned- It must be specified on all subsequent 
recyjests. The CEPID is an integer value whose range 
is -2**31 to 2**31-1. 



source 



o 



This parameter specifies the internet address and 
port address of the datagram source. The internet 
address is optional, and in the multihost systen, 
will specif iy the network solution used to send the 
datagram. There are a number of well known ports, an 
application not owning such a port should leave this 
field unspecified. All unspecified fields will be 
filled in and returned by TCP. 






The internet address (ip_address) is a 32 bit value 
whose range is -2**31 to 2**31-1. The port address 
is a 16 bit value whose range is to 2**15-1. There 
is a boolean value appended to the addresses that 
indicates whether a port address is specified. This 
value is set as follows: = TRUE, 1 = FALSE. 



destination 



This parameter specifies the internet address and 
port address of the destination application. 



%s 
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The internet address (ip_address) is a 32 bit value 
whose range is -2**31 to 2**31-1. The port address 
is a 16 bit value whose range is to 2**15~1. There 
is a boolean value appended to the addresses that 
indicates whether a port address is specified. This 
value is set as follows: = TRUE, 1 = FALSE. 



allocation 



Integer number of words the ULP will accept, 
is - 2*16. 



Range 



ip_header 



This is a 19-word record that contains the IP header 
for the data gram. This record is used by the ULP to 
pass header information to IP. The fielcte to be 
corrpleted by the ULP are specified below: 



J 



( 





Field 




Word 


Description 


Rar^ 





version 


0..15 


1 


ihl 


0..15 


2 


precedence 


0..7 


3 


ctelay 


Boolean 


4 


throughput 


Boolean 


5 


reliability 


Boolean 


6 


unusedjflag__l 


Boolean 


7 


unused_jflag__2 


Boolean 


8 


total_length 


0..0»-FFF(16) 


9 


identification 


O..OI-l-hF(16) 


10 


unusedjflagJS 


Boolean 


11 


dont_frag 


Boolean 


12 


more_ frags 


Boolean 


13 


frag offf^t 


0..011-I-FC16) 


14 


time__to__live 


0. .255 


15 


protocol 


0..255 



ULP 

Supplied 



V. J 



yes 

yes 

yes 

yes 

zero 

zero 

yes 

zero 
yes 



yes 
yes 



c 
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ULP 

S upplied 



0. .FFFF(16) 

-80 000 O0O..7FFFFFFF(16) 

-80 000 000..7FFFFFFF(16) 



ip_pptions 



This is a 47-word record that contains the IP options 
for this connection. It consists of four subrecords 
for security, stream id, routing, and timing. The 
format of this record shall be as follows: 



o 



o 





Field 




Word 


Description 


Ran9e 


0-5 


ip_sec_rec 


- 





zero 


0..127 


1 


in use 


Boolean 


2 


Facurity 


0. .0t-FFF(16) 


3 


corrpartments 


O..0FFFF(16) 


4 


handling 


O..Oht-K(16) 


5 


toe 


0..a^FFF(16) 


6-8 


ip streamid rec 


- 


6 


zero 


0..127 


7 


in__use 


Boolean 


8 


streamid 

ip_routig_rec 

zero 


O..OhH-(16) 


9-22 


- 


9 


0.127 


10 


injjse 


Boolean 


11 


rtype 


0..255 


12 


index 


0..255 


13 


count 


0..255 


14-22 


ip__list [array 0..83 


-80 000 000..7FFFFFFF(16) 


23-46 


ip_time stamp 


- 


23 


zero 


0..127 


24 


in use 


Boolean 



o 



o 
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Word 



Field 
Descri ption 



25 ttype 

26 index 

27 count 

28 overflow 

29-46 sum_array [array 0. .8] 

29-46 bg__array [array 0..3] 



0..255 

0. .255 

0. .255 

0..255 

ip_double_word 

ip_full_stamp 



ulp__tifneout 



push_flag 



v_,y 



urgent jf lag 



v.> 



data 



This is a pointer to the buffer containing data to be 
sent with the connect request. If there is no data 
to be sent with the request, then the pointer should 
be NIL. The TCP module assumes ownership of one copy 
of this buffer. 



data__length 



Integer count of number of words in data buffer. 



status 



This is the status returned as a result of the active 
connection rec^jest. The following integer values may 
returned; 



c: 



(6458W/WP35) 



CONTROL DATA PRIVATE 



3-206 



o 



HKSYSTM-003-ERS-OO-C 
10 December 1986 



tq3_connecti ng 
. tcp_sap_not_ppen 
tq3__il legal__source 
tcpji 1 legal jdesti nation 
tqD._illegal_option 
tcpjDonnect ion_i nuse 



no wait 



Boolean value, when true, causes routine to return 
immediately after issuing request. 



o 



3.8.3.1.2.4 TCP_Passive_Connect (TCPPC) Routine 

The TCP__Passive_Connect routine is called by the application to inform the 
TCP module that it is willing to acc^t connect indications from a peer. The 
peers address may be specified completely, partially, or not at all. When an 
active connect request is received by the TCP module, the application will be 
given an indication. The application may acc^t or reject the connection and 
the passive connect will remain in effect. The calling format shall be: 

CAU- TCPPC (tcp__sapid, user_cepid, tq^jsqsid, source, destination, 
allocation, ip_header, ip_options, ulp_timeout, pushjflag, 
status, no_wait) 



o 



tcp_sapid 



^tqDjEapid, user_cepid^ tcp._cepid, source, 
tination, alloc4*lon,ip_header, ip__q:>tions, 
ulp_tlbR^out, push_ti^g, status, no_wait) 



O 



user_cepid 



(645BW/WP35) 



(tcp._sapid,/^ user_cepid, tcp_cepid, source, 

destina)24^n, \allocation,ip_header, ip_options, 

ulpyt^meout, pushJKlag, status, no_wait) 



CofJ. 



(f ^.S.-^.l.l'!. JU "Call TcPAc(;; 



CONTROL DATA PRIVATE 



... • J 
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source 



destination 



options 



Ctcp_sap: 

destinatidl 

ulp_timeout 




id, source, 

r, ip_pptions, 

'no^wait) 



(tcp_sapid, C5iser__cepicK' tcp_cepid, source, 

desti nation , aiaoca;^on , ip_header , ip_options , 

ulp_timeout, pushjfl^, status, no__wait) 

The option param^fter sp^if ies a record that contains 
the option En(&;ification^or this connection. The 
following ^ a list of the options and their range 
values: 



o 



3.8.3.1.2.5 TCP_Allocate (TCF¥i) Routine 






The application calls TCP_Allocate routine to inform the TCP module how much 
data it is willing to accept on a given connection; that is, how much buffer 
space the application has available. The calling format shall be: 

CALL TCPA (tcp_cqDid, size, status , no_wait) 

r 

tap_c&pid This is the TCP CEPID which specifies this 

connection. The CEPID is an integer value whose 
range is -2**31 to 2**31-1. 



v.. 



size 



This is the number of bytes that the ^Dplication will 
acc^t from the TCP. 



status 



This is the returned status as a result of the 
allocation request issued by the application. The 
following integer values may be returned: 



tcp__al locat ion_acc^ted 
tcp._no__connection 



(64^W/WP35) 
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no wait 
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Boolean value, if true, causes routine to return 
immediately after issuing request. 






3.8.3.1.2.6 TCP__Status (TOPS) Routine 

The TCP_Status routine returns a copy of the status records that the TCP 
module is keying for this connection. The calling format shall be: 

CALL TCPS (tcp_cepid, user_cepid, tcpjEpa*, userjsapid, source, 
destination, ip_header, ip__options, ulp_timeout, 
tq3_stat__rec, status, no_wait) 



tcp_c^id 



This is the TCP CEPID which specifies this 
connection. The CEPID is an integer value whose 
range is -2**31 to 2**31-1, 



o 



user_cepid 



This is the CEPID which specifies this connection. 
The CEPID is an integer value whose range is -2**3i 
to 2**31-1. 



o 



tcp._sapid 



This is the SAPID returned by TCP in the open SAP 
request. The SAPID is an integer whose ran^ is 
-2**31 to 2**31-1. 



user__sapid 



This is a record that contains the user SAPID. The 
SAPID is an integer whose range is -2**31 to 2**31-1. 



source 



O 



This parameter specifies the internet address and 
port address of the datagram source. The internet 
address is optional, and in the multihost system, 
will specifiy the network solution used to send the 
datagram. There are a number of well known ports, an 
application not owning such a port should leave this 
field unspecified. All unspecified fields will be 
filled in and returned by TCP. 



o 
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o 



The internet address Cip__address) is a 32 bit value 
whose range is -2**31 to 2**31-1. The port address 
is a 16 bit value whose range is to 2**15-1. There 
is a boolean value appended to the addresses that 
indicates whether a port address is specified. This 
value is set as follows: = TRUE, 1 = FALSE. 



c 



destination 



This parameter specifies the internet address and 
port address of the destination application. 



The internet address (ip_address) is a 32 bit value 
whose range is -2**31 to 2**31-1. The port address 
is a 16 bit value whose range is to 2**15-1, There 
is a boolean value appended to the addresses that 
indicates whether a port address is specified. This 
value is set as follows: = TRUE, 1 = FALSE. 



.J 



ip_header 



This is a 19-word record that contains the IP header 
for the data gram. This record is used by the ULP to 
pass header information to IP. The fields to be 
coffpleted by the ULP are specified below: 





Field 




)rd 


Description 


Range 





version 


0..15 


1 


ihl 


0..15 


2 


precedence 


0..7 


3 


delay 


Boolean 


4 


througtput 


Boolean 


5 


reliability 


Boolean 


6 


unused_flag_l 


Boolean 


7 


unused„flag_2 


Boolean 


8 


total__length 


O..U(-l-H-(16) 


9 


identification 


O..OI-l-hh(16) 



ULP 
Supplied 



yes 

yes 

yes 

yes 

zero 

zero 

yes 
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Field 








ULP 


Word 


Description 


Range 






Supplied 


10 


unused flag 3 


Boolean 






zero 


11 


don t frag 


Boolean 






yes 


12 


more J= rags 


Boolean 








13 


fragjDffset 


0..01I-I-KC16) 








14 


time_to_live 


0. .255 






yes 


15 


protocol 


0..255 






yes 


16 


checksum 

source 


0..H-|-K(16) 
-80 000 000., 








17 


.7FFFFFFF(.16J 




18 


destination 


-80 000 000. 


./t-|-l-l-hH-(16) 




ip_pptions 


This is a 47-word 


record that contains 


the IF 


' option; 



o 






o 



for this connection. It consists of four subrecorcte 
for security, stream id, routing, and timing. The 
format of this record shall be as follows: 



Range 

0. .127 

Boolean 

0..0FFFF(16) 

O..0FFFF(16) 

0..0FFFF(16) 

O. ,0FFFF(16) 

0. .127 

Boolean 

0..0FFFF(16) 

0.127 

Boolean 

0..255 





Field 


Word 


Description 


0-5 


ip_sec_rec 





zero 


1 


injjse 


2 


security 


3 


compartments 


4 


handling 


5 


tec 


6-8 


ip streamid rec 


6 


zero 


7 


in_.use 


8 


streamid 


9-22 


ip__routig__rec 


9 


zero 


10 


injJse 


11 


rtype 



o 



o 
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Field 








Word 


Description 




Ranqe 




12 


index 




0..255 




13 


count 




0..255 




14-22 


ip_list [array 0. . 


8] 


-80 000 000. .71 




23-46 


ip_time stamp 




_ 




23 


zero 




0..127 




24 


injjse 




Boolean 




25 


ttype 




0..7SS 




26 


index 




0..255 




27 


count 




0..255 




28 


overflow 




0..255 




29-46 


sum_array [array 


-.8] 


ip_double_word 




29-46 


bg_array [array 0. 


.3] 


ip_full_stamp 


ulp__tifneout 











o 



V 



V_v 



tq3__stat_rec 



This parameter specifies a 13-word record containing 
the TCP status record. The record layout is as 
follows: 



Word 



t)escription 



Range 







0-1 


ULP_timeout 


ulp_timeout_rec 






2 


pdu_si2e 


0-2**12 






3 


allocation 


0-2**59 






4 


fsm_state 


0-2**59 






5 


unsent 


0-2**59 






6 


sentjjnacked 


0-2**59 


o 


(6458W/WP35) 
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sent_total 
CONTROL DATA PRIVATE 


0-2**59 
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Word 


Description 
undelivered 


Range 


8 


0-2**59 


9 


recjjnacked 


0-2**59 


10 


rec_total 


0-2**59 


11 


rndtrip_time 


0-2**15-1 


12 


retrans cxxint 


0-2**59 






status 



This is the returned status as a result of the status 
request issued by the application. The following 
integer value may be returned: 



^klj^ilJlT 



no wait 



tcp_status__<X)fnplete 
tcp__no_conneotion 

Boolean value, if true, causes routine to return 
irmnediately after using request. 



3.8.3.1.2.7 TCPJDisconnect (TCPD) Routine 

The TCP_Disconnect routine is called by the ^splication to terminate a 
connection. The application must wait until it receives a confirmation 
before assuming that the connection is dead. The application must also be 
willing to continue accepting data from the peer until the disconnect is 
confirmed. The calling format shall be: 

CALL TCPD (tcp_c^id, status, no_wait) 



o 



tcp_c^id 



This is the TCP CEPID which specifies this 
connection. Tt-e CEPID is an integer value whose 
range is -2**31 to 2**31-1 . 



O 
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status 



This is the returned status as a result of the 
disconnect rec^^est issued by the aicplication. The 
following inte^r value may be returned: 



C^' 



no wait 



top__disconnecting 
tcp__no__connection 

Boolean value, if true, causes routine to return 
immediately after issuing request. 



3.8.3.1.2.8 TCP_AbortJXirrent_Connection (TCPACC) Routine 

This TCP_Abort„Current_Connection routine is called by the application to 
abort a current connection. Unlike the disconnect routine, this routine 
disconnects immediately and any data in transit from the peer is thrown away. 
The calling format shall be: 



CA1_L TCPACC (tcp_c&pid, status, no_wait) 



tcp_c^id 



This is the TCP CEPID which specifies this 
connection. The CEPID is an integer value whose 
range is -2**31 to 2**31-1. 



vy 



status 



This is the returned status as a result of the abort 
request issued by the application. The following 
integer value may be returned: 



tcp_aborted 
tcp_no_connection 



no wait 



Boolean value, if true, causes routine to return 
immediately after issuing request. 
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3.8.3.1.2.9 TCP_Sencl.pata (TCPSD) Routine 



\^ 



The TCP._Send_JData routine is called by the application to send data on an 
established connection. This routine has two special parameters, the PUSH 
flag and the URGENT flag. These two parameters tell TCP to give the data 
special processing. The calling format shall be: 

CPLL. TCPSD (tq3_cepid, push, urgent, ulp_timeout, data, data_length, 
status, no._wait) 



tcp_cepid 



This is the TCP CEPID which specifies this 
connection. The CEPID is an inte^r value whose 
range is -2**31 to 2**31-1. 



o 



push 



This flag is set TRUE to force the TCP module to 
immediately send the csjrrent data and any previous 
data to its peer. The flag is a boolean value, = 
TRUE and 1 = F«-SE. 



o 



urgent 



When this flag is TRUE the data sent will be marked 
as special ur^nt data. The flag is a boolean value, 
= TRUE and 1 = FAL^. 



ulp__,timeout 






This is a pointer to the buffer that contains the 
data to be sent. It is assumed that the TCP mo<±ile 
is given ownership of one copy of the buffer. 



o 



data_.length 



Integer count of number of words of data to send. 
Range is 0..2**32-l, 



o 
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status 



This is the status returned as a result of the send 
data recpest. The follcxging integer value niay be 
returned: 



tcp_send_cofrplete 
tcp__no__connection 
tq3_buffer__lost 



no wait 



Boolean value, if true, causes routine to return 
immediately after issuing request. 



3.8.3.1.2.10 TCP__Aoc€^tJ[ndication (TOPAI) Routine 

The TCP__Acc^t_Indication routine is called by the application to check for 
indication arrival. The arriving indications are either the result of a peer 
connection rec^jest atterrpt (TCP_Connect_Indication) or a data indication from 
the peer (TOP_Data„Ind). The calling format shall be: 



CALL TOPAI (id, buffer, length, status, no_wait) 



id 



This is the CEPID or SAPID for the TCP connection to 
poll. If -1, all TCP connections/SAPS are polled. 



buffer 



Buffer to be used to receive reply data. 



length 



Integer length of buffer supplied, in connection data 
units (default is 8-toit bytes). __. 

• too indication acnp»tp»d \ r f 



tcp_i ndicati on__accepted 
tcp_no_indication 



no wait 



Boolean value, if true, causes routine to return 
immediately after issuing request. 
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3,8.3.1.2.10.1 TCP Connection_Jndication 



The TGP_Connect_Indication is used by TCP to inform the application that a 
connection rec^jest has come in from another application on the network. The 
following information is supplied with the indication: 



user_c^id 



This is the Connection End Point Identifier (CEPID) 
which will be provided by TCP with all data passed to 
the application. CEPID is an integer value of range 
-2**31 to 2**31-1. 



destination 



This parameter specifies the internet address and 
port address of the destination application. 



o 



The internet address (ip__address) is a 32 bit value 
whose range is -2**31 to 2**31-1. The port address 
is a 16 bit value whose range is to 2**15-1. There 
is a boolean value appended to the addresses that 
indicates whether a port address is specified. This 
value is set as follows: = Tf?UE, 1 = FALSE. 



ip_header 



This is a 19-word record that contains the IP header 
for the data gram. This record is used by the LLP to 
pass header information to IP. The fields to be 
co(Tpleted by the ULP are specified below: 



o 







Field 






Word 


Description 


Range 







version 


0. .15 




1 


ihl 


0..15 




2 


precedence 


0..7 




3 


delay 


Boolean 




4 


throughput 


Boolean 




5 


reliability 


Boolean 


(6458W/WP35) 
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ULP 

Sup plied 



yes 
yes 

yes 
yes 



O 
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Word 


Field 
Description 


Range 




LLP 

Supplied 


6 


unused_flag_l 


Boolean 




zero 


7 


unused__flag__2 


Boolean 




zero 


8 


totalJLength 


0..0l-l-l-F(l6) 






9 


identification 


O..OI-hl-K(16) 




yes 


10 


unused jflag_3 


Boolean 




zero 


11 


dontjfrag 


Boolean 




yes 


12 


morejfrags 


Boolean 






13 


frag_offset 


0..01l-f-K(16) 






14 


time__to_live 


0. .255 




yes 


15 


protocol 


0..255 




yes 


16 
17 
18 


checksum 


0..I-I-|-J-(16) 






source 


-80 000 000.. 


7hKI-hl-hh(16) 




destination 


-80 000 000,. 


/hl-hl-l-l-h(16) 




ip_cptions 


This is a 47-word 


record that cc 


»ntains the IF 


> options 



for this connection. It consists of four subrecorcte 
for security, stream id, routing, and timing. The 
format of this record shall be as follows: 



V^^ 



~\ 





Field 


Word 


Description 


0-5 


ip_sec_rec 





zero 


1 


in_use 


2 


security 


3 


compartments 


4 


handling 


5 


tec 


6-8 


ip streamid rec 


6 


zero 


7 


in__use 


8 


streamid 



Range 

0..127 

Boolean 

O..OFFFF(16) 

0..0FFFFC16) 

O..OFFFF(16) 

O..OFFFF(16) 

0..127 

Boolean 
O..OFFFF(16) 



o 
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Field 








Word 


Description ■ 




Range 


9-22 


ip_routig 


_rec 




- 


9 


zero 






0.127 


10 


in_use 






Boolean 


11 


rtype 






0. .255 


12 


index 






0..255 


13 


count 






0..255 


14-22 


ipJList [array 0. 


.8] 


-80 000 000..7l-|-FHhFF(16) 


23-46 


ip_time s 


tamp 




- 


23 


zero 






0..127 


24 


injjse 






Boolean 


25 


ttype 






0. .255 


26 


inctex 






0..255 


27 


count 






0..255 


28 


overflow 






0..255 


29-46 


sufn_array 


[array 


0..8] 


ip_double__word 


29-46 


bg„array 


[array 


-.3] 


ip_full_stamp 


ulp timeout 











o 



o 



o 




jnt integer 

overflow inte^r 

stamp_type integer 

time_stafrp_array_0 array 

full__stamp_array_l_3 array 



time_stamp_2 
inuse 



stream 
strfe 



id 



none 

boolean 

integer 




1 to 2**6-2 
to 2**4-1 
0,1,2, or 3 
[0. . .2**6-23 

of time_.stamp 
[0... 2**5-1] 

of full__stamp 

= TRUE, 1 = FPLSE 
to 2**15-1 
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data 



This is a pointer to the buffer containing the data 
sent with the connect request. If no data was sent 
then the pointer will be NIL. The application is 
assumed to acc^t ownership of one oc^y of this 
buffer. 



c 



data length 



Integer value of length of data buffer in connection 
units. 



3.8.3.1.2.10.2 TCP_pata_Ind 

The TCPJ)ata_Ind is used by TCP to inform the application of data and 
non-connect rec^jest indications from an application on another network. The 
following information is supplied with the indication. 



user_cepid 



\.J 



This is the user CEPID that was provided by the 
application at the time of the connect request. CEPID 
is an integer value of range -2^*31 to 2**31-1. 



\..y 



ind_type 



This is the type of indication that is being 
presented. The following types are ctefined as 
integer values of range to 2**15-1. 



tcp__disconnec t_i nd 

tcp__disoonnect_conf 

tcp_data_ind 

tcpjjrgent__ind 

tcp_error__ind 

tq:>_abort_ind 

tcpjstartJLnd 

tcp_stop__ind 
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1^) f) 

^> data This is a pointer to the buffer that contains the ^--^ 



This is a pointer to the buffer that contains the 
data. The ownership of one copy of the buffer is 
assumed to be acc^ted by the application. In the 
case of a datajindication or an urgent_indication, 
the buffer will contain the datagram received. In 
the case of an abort_indication or an 
errorjindication, the buffer will contain an integer 
indicating the reason: 

tcp_timeout 
tqo_remote_abort 



3.8.3.1.3 IP primitives 

3.8.3.1.3.1 IP_Open_Sap (IPOS) Routine 



The open SAP routine is used to register a Service Access Point (SAP) with 
the IP module. The IP module allows a total of 254 SAPs to be open at one 
time. Each SAP is identified by its SAPid value which is linked to the 
protocol value. The calling format shall be: 



CALL IPOS (protocol, sapid, status, no_wait) 

protocol This value specifies the application protocol to the 

IP module. There are a number of well known values 
for authorized applications. Other applications 
should use the value zero, in which case the actual 
value will be assigned by the IP module, and will be 
returned. Protocol in an integer value whose range 
is to 2**8-1. 

sapid This is a 32 bit value returned that identifies the 

particular IP SAP in all later requests. SAPID is an 
integer value of range -2**31 to 2**31-1. ^^11,^. 

o o 
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status 



This is the status of the open SAP request, 
following integer values may be returned: 



The 



ip__sapjDpen 
ip_protoool_i nuse 
ip_protocol_.i 1 legal 



^-N, 

^4^' 



no wait 



Boolean value, if true, causes routine -to return 
immediately after issuing request. 



3.8.3.1.3.2 IP_Close_Sap ilPCS) Routine 

The close SAP is used to terminate the use of an IP SAP. This frees up the 
SAP for use by another application. The calling format shall be: 

CALL IPCS (protocc5l, sapid, status, no_wait) 



protocol 



This value specifies the application protocol to the 
IP mockJle. There are a nunnber of well known values 
for authorized applications. Other ^splications 
should use the value zero, in which case the actual 
value will be assigned by the IP module, and will be 
returned. Protocol in an integer value whose range 
is to 2**8-1. 






sapid 



This is the SAPid returned on the original open SAP 
request. SAPID is an integer value whose range is 
-2**3i to 2**31-1. 



status 



This is the returned status of the close SAP 
request. The following integer values may be 
returned: 



ip_sap_not_open 
ip jsap__plosed 
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Boolean value, if true, causes routine to return 
immediately after issuing request. 






3.8.3.1.3.3 IP__Sencl._Req (IPSR) Routine 

The send data routine is used to send data out on the network through a a 
previously opened SAP. The address of this routine is returned to the 
application when the open recpjest is made. 

CALL IPSR (header, source, destination, options, sapid, data, 
data__length, status, nojwait) 



header 



This is the IP datagram header as defined in section 
3.8.3.1.2.3. 



o 



source 



This is the address of the sender. This address may 
be partially or completely unspecified. This address 
is specified when an application needs to indicate 
which network solution the IP should use if it is 
multihomed. 



destination 



The source is a record made up of the following 
integer values: 



field_inuse 




integer 




M;0= net 
bit ^ = host 




network: 




integer 




to 2**20-1 




host: 




integer 




to 2**27-1 




This is the address 


of 


the remote 


IP 


that the data 


is 


being sent to. 













o 
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field_inuse 


integer 


bit 1 = net 




- 




bit 2 = host 




network: 


integer 


to 2**20-1 




tx>st: 


integer 


to 2**27-l 



o 



cptions 



sapid 



This is the IP options records as defined in section 

3,<S.3>. 1.2,2. 

This is the Service Access Point ID that was returned 
by the original open request. The SAPID is an 
integer value whose range is -2**31 to 2**31-1. 



data 



This is a pointer to the executive buffer returned 
containing the data portion of the message. 



V, J 



data__length 



status 



Integer length of data buffer in connection units. 

This is the status of the request. The following 
integer values may be returned: 



V. 



ip_net_u nreachable 
ip _host_unreachable 
iP-jfi'^gmentation needed 
ip j:ption_error 

ip_sap__not_ppen 
ip__source__illegal 
ip__desti nation JL 1 legal 



no wait 



Boolean value, if true, causes routine to return 
imrrediately after issuing request. 
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3.8.3.1.3.4 IP_Accept_Inclication (IPAI) Routine 






The IP__Accept_Indication routine is called by the application to check for 
indication arrival. The arriving indications are either the result of a p?^r 
data indication (IP_Data__Ind) or an error indication (IP_E:rror_Ir>d). 

CALL IPAI (sapid, no_wait) 



sapid 



This is the Service Access Point ID that was returned 
by the original open SAP request. SAPID is an 
integer value of range -2**31 to 2**31-1. 



no wait 



Boolean value, if true, causes routine to return 
immediately after issuing request. 



o 



3.8.3.1.3.4.1 IP__Data_Ind 

The IPJ>ata_Ind is used by the IP module to present data messages to the 
application. The following information is supplied with the indication: 



O 



header 



This is the IP datagram header as defined in section 
3.8.3.1.2.3. 



source 



This is the address of the IP that sent the data 
message. 



The source is a record made up of the following 
integer values: 



o 
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field__inuse 


integer 


bit 1 = net 
bit 2 = host 


network: 


integer 


to 2**20-l 


host: 


integer 


to 2**27-1 
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destination 



This is the address of the receiver. This address 
indicates which network solution IP received the 
message from in a multi-homed system. 



o 



The destination is a record made up of the following 
integer values: 



fieldJLnuse 


integer 


bit 1 = net 
bit 2 = host 


network: 


integer 


to 2**20-1 


host: 


integer 


to 2**27-l 



options 



This is the IP options records as ctef ined in section 
3.8.3.1.2.3. 



v.,y 



sapid 



This is the SAPid that was returned by the original 
open request. SAPID is an integer value of range 
-2**31 to 2**31-1. 



^.V 



data 



This is a returned pointer to the data buffer. 



data_length 



Length of data buffer in connection data units. 



3.8.3.1.3.4.2 IP Error Ind 



The IP__Error_Ind is used by the IP module to present error messages to the 
application. The following information is supplied with the indication: 



^^ 



ne Toxiowing inrormaLion is supplied with the indication: \ 



\fi^ r^ 
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error 



O 



/"axjnt 


— 


integer 


1 to 2**6-r"~~""""''Vw 


/ route_array 




array 


[0.. 2*1^-2] \*^^ 
of ip address \ 


time_stanp_i nuse 




boolean 


= TRUE, 1 = FALSE \ 


count 




integer 


1 to 2**6-2 \ 


overflow 




integer 


to 2**4-l \ 


starrp__type 




integer 


0,1,2, or 3 


time_stanrp_array_ 


p 


array 


[0. .2**6-2] 

of time__stamp 


1 full__stamp_array_ 


.1_ 


_3 array 


[0. .2**5-1] 

of full_stanrp / 


tifne_stannp_2 




none 


/ 


streamjLnuse 




boolean 


= TRUE, 1 = FALSE / 


\ stream id 




integer 


to 2**15-1 ^^ 






This is the type of error that occurred, 
following errors are defined: 

ip_net_unreachable 

ip_ hos t_u nreaohable 

ip_protocol_unreachable 

ip_portjjnreachable 

ip__fragfT)entation_needed 

ip_rou te_f ai led 

ip__timeout 

ip_ass&iibly__timeout 

ip_option_error 

ipjDongestion 



The 



o 



(6458W/WP35) 



CONTROL DATA PRIVATE 



o 



3-227 



HKSYSTM-003-ERS-OO-C 
10 December 1986 

bad__param 



This is the index of the bad parameter in the options 
list. The first parameter is precedence whose offset 
is 0. This is an integer value. 



3.8.3.1.4 TELNET Primitives 



3.8.3.1.4.1 TEUsET Active Connect Recpjest (TELACR) 



telnet_.sapid 


CD 


: ITTSAPID, 


user_cepid 


(I) 


: UCEPID, 


source 


(I/O) 


: T$SADR$REC, 


destination 


(I) 


: T$DADR$FEC, 


tcp_timeout_opt 


(I) 


: ULPTMOUT, 


ip heacter 


(I) 


: IP$HDR$REC, 


iP_options 


(I) 


: IP$OPT$REC, 


tcp_al location 


(I) 


: Alloc, 


£pecial_byte 


(I) 


: TNSPE$8YT, 


perform_echo_opt 


(1) 


ThECO$OPT, 


log„csonnect_msg 


(I) 


: TNLOG$CON, 


log statistics 


(I) : 


TM_CDG$STA, 


peer_pcl__errs__alwd 


(I) : 


TNPER$ERR, 


push 


(I) : 


TPUSH, 


urgent 


(I) 


TPURG, 


tcp__data 


(I) 


III DATA, 


data_length 


(I) 


ITTSIZE, 


telnet_c^id 


(0) : 


TCEPID, 


status 


(0) 


TIMSTATUS, 


no_ wait _ 


(I) : 


boolean) 



Vy 



3.8.3.1.4.2 TELNET Abort Rec^jest (TELAR) 



( 






telnet_c^id 


(I) 


: TCEPID, 


status 


(0) 


: TNSTATUS, 


no._wait 


(I) 


: boolean) 



o 
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v>' 



telnet__c^id 


(I) 


: TCEPID, 


push 


(I) 


: TRJSH, 


tcp__tifneout_opt 


(I) 


: ULPTMOUT, 


cxjfnmand oDde 


(I) 


: TNCOM$COD, 


status 


(0) 


: TNSTATUS, 


no__wait 


(I) 


: boolean) 



3.8.3.1.4.4 TELhET Close Sap (TELCS) 



telnet sapid 


CD 


: ITTSAPID, 


status 


(0) 


: TNSTATUS, 


no_wait 


CD 


: boolean) 



3.8.3.1.4,5 TELNET Disconnect Request (TELDR) 



o 



telnet_c^id 


CD 


: TCEPID, 


status 


CO) 


: TNSTATUS, 


no__wait 


CD 


: boolean) 



3.8.3.1.4.6 TELNET Flow Control ftequest CTELFCR) 



telnet_cepid 


CD 


: TCEPID, 


flow__cntl_status 


CD 


: TFLO$CTL, 


status 


CO) 


: TNSTATUS, 


no_wait 


CD 


: boolean) 



3.8.3.1.4.7 TELNET Option Data Request CTELODR) 



o 



telnet cepid 


CD 




: TCEPID, 


push 


CD 




: TRJSH, 


tcp_t i meou t jDpt 


CD 




: ULPTMOUT, 


option_oode 


CD 




: T^DPTION, 


C6458W/WP35) 
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optionjdata 


(I) 


: TNOPT$DTA, 


clata__length 


CD 


ITTSIZE, 


statxis 


(0) 


: TNSTATUS, 


no__wait 


CD 


boolean) 



o 



3.8.3.1.4.8 TELNET Option Request (TELOR) 



telnet oepid 


(I) 


: TCEPID, 


push 


(D 


: TPUSH, 


top_timeout_opt 


(D 


: ULPTMCXrr, 


option„negotiation 


(D 


: TNOPT$NEG 


option_cocle 


(I) 


: TNDPTIQN, 


status 


(0) 


: TNSTATUS, 


no__wait 


(I) 


: boolean) 



3.8.3.1.4.9 TELNET Open Sap (TELOS) 



K.y 



user_sapicl 


(D 


: USAPID, 


telnet sapid 


(0) 


: ITTSAPID, 


status 


(0) 


: TNSTATUS, 


no_wait 


CD 


: boolean) 



3.8.3.1.4.10 TELNET Passive Connect Request CTELPCR) 



o 



telnet sapid 


CD 


: ITTSAPID, 


user_pepid 


CD 


: UCEPID, 


source 


Ci/0) 


: T$SADR$REC, 


destination 


CD 


T$DADR$REC, 


tcp__timeout_opt 


CD 


: ULPTMOUT, 


ip_.header 


CD 


IP$HDR$REC, 


ip _pptions 


CD 


IP$OPT$REC, 


tcp__al location 


CD 


ALLOC, 


special_byte 


CD 


TNSPE$BYT, 


perform_echo_opt 


CD : 


TNECOSOPT 
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log_connectjnsg 


(I) 


: TNLOG$CON, 




logjstatistics 


(I) 


: TNLOG$STA, 




peer j3cl _errs_alwcl 


(I) 


: TNPERSERR, 




telnetcepid 


(0) 


: TCEPID, 




status 


(0) 


: TNSTATU, 




no__wait 


(I) 


: boolean) 





3.8.3.1.4.11 TELNET User Data Request (TELUDR) 



o 



telnet_cepicl 


(I) 


: TCEPID, 


push 


(I) 


: TPUSH, 


tcp_t imeou t_op t 


(I) 


: ULPTMOLTT, 


line complete 


(I) 


TNLINSCMP, 


process text 


(I) 


: TNPROSTXT, 


user_data 


(I) : 


ITTDATA, 


data_length 


(I) 


: ITTSIZE, 


status 


(0) : 


TNSTATUS, 


no_wait 


(I) 


boolean) 



o 



3.8.3.1.4.12 TELNET Indication Primitive Calling Sequences 



These routines are suppli^ by the application program. 



3.8.3.1.4.12.1 TELNET Abort Indication (TELAI) 



user_cepid 
abort code 



CD 
(I) 



: UCEPID, 
: TNABORT 



3.8.3.1.4.12.2 TELNET Command Indication (TELCI) 



user_cepid 
command code 



(I) 
(I) 



: UCEPID, 
: TNCC3M$C0D 



o 
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3,8.3.1.4.12.3 TELhET Connect Request Indication (TELCRI) 



O 



user__cq3id 


(I) 


: UCEPID, 


destination 


(I) 


: T$DADR$REC, 


■tcp_t imeou t_opt 


(I) 


: ULPTMOUT, 


ip header 


(I) 


: IP$HDR$REC, 


ipjDptions 


(I) 


: IP$OPT$REC, 


tqD_data 


(I) 


: IIIDATA, 


data_length 


(I) 


: ITTSIZE) 



3.8.3.1.4.12.4 TELNET Disconnect Confirm (TELDC) 



user_cepid 



(I) 



UCEPID) 



3.8.3.1.4.12.5 TELNET Disconnect Indication (TELDI) 



user_c^id 



(I) 



: UCEPID) 



3.8.3.1.4.12.6 TELNET Error Indication (TELEI) 



user_c^id 
error code 



(I) 
(I) 



: UCEPID, 
: TTCRROR) 



3.8.3.1.4.12.7 TELNET Flow Control Indication (TELFCI) 



user_c^id (i) 
flow_cntl__status (I) 



: UCEPID, 
: TFLOSCTL) 



3.8.3.1.4.12.8 TELNET Option Data Indication (TELODI) 



o 



user_cepid 


(I) 


: UCEPID, 


option code 


(1) 


: TNOPTION, 


option_data 


(I) 


: TNOPT$DTA, 


data__length 


(I) 


: ITTSIZE) 
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o 



user_cepid (I) 
option__negotiation (I) 
option_code (I) 



: UCEPID, 
: TNOPT$NEG, 
: TNOPTICDN) 



3.8.3.1.4.12.10 TELNET User Data Indication (TELUDI) 



user cepid 


(I) 


: UCEPID, 


line cooplete 


(I) 


: TNLINSCMP, 


user data 


(I) 


: ITTDATA, 


data__length 


(I) 


: ITTSIZE) 



-3.8.3.1.5 Common Routines 



o 



Several common routines have been identified for use by DDN system 
applications such as FTP, SMTP, and Supervisor. These routines are not 
supported for users nor do they appear in the User Manual. 






3.8.3.1.5.1 DDN /=toort Processing - DDNABT 

DDmBT is used to ^Dort a DDN application due to some irrecoverable error. 
First, NETDMB is called to dump the program. Next, the message is issued to 
the dayfile, and if possible, to the DDN Supervisor. Then, any NET files 
(trace, statistics) are flushed and an abort is issued. 

CALL DDNABT (message) 



o 



message 



A character string, up to 40 characters long and 
zero-toy te terminated, containing the reason for the 
abort. Every call to DDNABT must use a unique 
message (within the program). 



o 
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^j) 3.8.3.1.5.2 Check QTGET response - DDNCQTG. (fj) 

DDNCQTG is used to perform standard processing following a QTOEJ call. It 
performs the following tasks: 

a. Handles DDN specific data. This includes asnynchronous or 
synchronous supervisory messages for connections that are maintained 
by the DDN runtime routines DDNxxxx, TCPxxxx, IPxxxx, TELxxxx, 
SMTPxxx, and FTPx>oo<. 

b. Logs (using DDNLM) certain error status from QJOEJ, including GTOEJ 
errors 6,13,23,63, all 'reserved' nurrtDers, and all numbers that are 
not returned by QTGET (5,11,12,15,22,43,44). 

c. Processes debugging and statistics requests from t^lftA. 
If a 36 is received, QTDMB is called. 

If a 37 is received, DEBUG is set true in DDNCC3M. 

If a 38 is received, DEBUG is set false in DDNCXDM. ( ^ 

If a 39 is received, QTSTC is called. 

If a 40 is received, QTREL is called. 

d. Maintains the connection state in the NOT entry. 
If a 6 is received, sets 'unused' (terminated) state. 
If a 20 is received, sets 'unused' (terminated) state. 
If a 42 is received, sets 'inactis/e' state. 



e. Maintains the network state in DDNCOi. 

If a 9 is received, sets 'idledown' state. 
If a 10 is received, set 'terminated' state. 

f . Continues processing initiated by a DDNLINK request. The following 
error codes are processed if the connection is started by a DDNLINK 
call, and otherwise ignored: 

o o 
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/ If a is received and the conna^tion state is 'connected' then the \^ 

data is validated as an application ID. The connection state is 
either advanced to 'identified' or the connection is terminated. If 
'identified' and no ID has previously been sent, it is sent to the 
app now. 

If a 2 or 14 is received, the connection state is advanced to 
'connected', and an Application ID is sent if ^apropriate. 

g. The following are not processed (unless DDIM-runtime mana^d): 
0,1,2,7,8,14,18,19,21,24,25,26,27,28,31,32,33,34,35. 

h. Even though DDNCQTG does some processing on certain codes, the 
application may also have to do processing on the codes. If the 
application should not do processing on the QTGET data, DDNCQTG will 
reset the return code to 1. Following are recommencted actions to be 
taken by an application for codes that are partially process^ by ^„> 
fjj ■ .DDNCQTG: VJ 

2 - The application should send (or wait for) data depending on the 
protocol. DDNCQTG will not return a '2' status until 
application IDs have been exchanged. 

6 - Additional clean-up by tl^ application will prctoably be 
rec|uired after a broken connection, particularly if there are 
related connections open that must be informed or closed. 

9 - The application should send termination notices to all 
^Dplicable connections and abort any passive TCP/IP/TELNET or 
otherwise idle connections. 

10 - Files should be flushed and the program should terminate. 

o o 
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\i J^ i3 - Send necessary error responses to users and clean up tables. 

14 - The application should send (or wait for) data depending on the 
protocol. DDNCQTG will not return a '14' status until 
application IDs have been exchanged. 

39 - The application should reset its own statistical counters. 

42 - The application, if appropriate, should poll the other user to 
determine if still present, or possibly close the connection 
(resoree to this case is TBD for FTP/SMTP). 

The calling sequence for DDNCQTG is: 

CALL DDNCQTG (buffer, status) 

buffer kxjffer supplied in original OTGET call. 

status Return status. This is the status in the NIT from the 
QJGET call and possibly changed by DDNCQTG. 

3.8.3.1.5.3 Get DDN Network Data - DDNC^T 

DDNCST is used to receive data from applications, or to receive asynchronous 
supervisory messages. DDNC^T issues a QTGET with the supplied parameters and 
then calls DDNCQTG to process the return status. 

CALL DDNC^T (buffer, length, acn, status, no_wait) 

buffer Array to receive data. 

length Length of buffer in connection data units (default is 
8-bit bytes). In general, this should be the maximum NPM 
block size. 
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Vv' acn Connection number to be polled. If zero, only V^ 

asynchronous messages are polled. If -1, data is accepted 
from any connection, and acn is updated by DCiNi^T to the 
acn for data received. 

status Return status from the QTC^T/DDNCQTG call. 

no_wait Boolean value, if true, causes routine to return 
immediately after issuing request. 

3.8.3.1.5.4 ^^lication Idle Processing - DDNIDLE. 

DDNIDLE is used to handle rollout and recall processing for DDN 
applications. PECPLL is called for a period of time, after which if no 
network data has arrived, then bETWAIT is called to rollout the application. 
The rollout and recall parameters are set with defaults in common block 
^^ DDNCXDM and can be changed dynamically by the application if desired. DDNIDLE ^my 
%^ takes rK> parameters. ^^ 

CALL DDNIDLE 

3.8.3.1.5.5 Application Connection Processing - DDNLINK 

DDM_INK is used to connect to another DDN application, and to establish which 
protocols are supported for incoming connection requests. Only one DDNLINK 
or QTLINK can be outstanding at one time. DDNLINK performs a QTLINK 
automatically and additionally, through DDNCQTG, sends the application ID and 
verifies the ID sent by the connecting application. When an ID has been sent 
and a valid ID has been received, DE^siCQTG returns a 2 or 14 code (depending 
on which application initiated the connection) indicating that the connection 
is ready for data transfer. 



o o 
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CPLL DDNLINK (application_.name, destination^host, outoall, length, 
protocol, status, no_wait) 



o 



application name 



0-7 characters containing name of application with 
which to connect. If zero, then this call specifies 
or de-specifies a protocol for which the application 
will accept inbound connection requests. 
Application_nafTie is the NAMEl portion of NAM 
connections. 



destinationjTost 0-3 characters containing destination host. This 

should be zero for intra-host connections. 
Destination_.host is the NAME2 portion of mn 

connections. 



outcall 



vy' 



Buffer containing outcall parameters. Only SSJ= jobs 
can send outcall parameters. For intra-host 
connections, the first byte of user call data is 
reserved for SSJ= identification. Outcall parameters 
other than user call data should not be used for 
intra-host connections. 



V,_y 



callen 



Length of outcall buffer in 8-bit bytes. Zero if no 
outcall parameters are specified. 



protocol 



Protocol identifier and version. See NOT for 
description. For incoming connection recjuests, a 
call must be made to DDNLINK (with ^Dpname=0) for 
every protocol that the application supports. These 
calls must be macte after the DDNSSA call but before 
the DDNRA call. If an incoming appl-id does not 
match protocol id or version, then the mismatch is 
logged and the connection is broken. 



o 
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Status frcxD QTLINK. 



o 



no wait 



Boolean value, if true, causes routine to return 
imnnecliately after issuing request. 



3.8.3.1.5.6 Send DDN Network Data - DDNPUT. 

DDNPUT is used to send data or supervisory messages to an application. 
DDNPUT calls QTPUT with the supplied parameters. 

CPLL DDNPUT (buffer, length, acn, endmsg, qual, status, no__wait) 



buffer 



Array buffer containing data or messages to send. 



O 



length 



acn 



Number of connection data units in buffer (default is 
8-bit bytes). 

Connection nurrtoer over which to send data. 



\j) 



endmsg 



End-of -message flag. Boolean value, if true, this is 
the last (or only) block in a message. 



qual 



Qualified data flag. Boolean value, if true, the 
data is sent as qualified data. 



no wait 



Boolean value. Unused, kept for consistency. 



3.8.3.1.5.7 Set System Ppplication - DDNSSA. 



o 



DDNSSA allows an application to establish itself as a DDN system 
application. This means that the application can use the standard DDN 
interface routines (for example, TCPxxxx) ard can also use the QTIW routines 
and DDNC^T/DDNPUT routines. DDN applications that use both types of routines 
arB responsible for allocating the NIT and NCT. They are also responsible 
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for using DDNGET instead of QTGET so that data destined for connections 
handled by the interface routines (for exarrple, TCP>ooo<) can be processed. 
The application should not do anything directly with these connections (they 
are identified by a flag in the IMCT). 



c 



J 



CALL DDNSSA (nit, nitlen, net, nctlen, sysflag, no.jwait) 



nit 



Array to be used for the Network Information Table. The 
application should not set any values into this table; it 
will be initialized by DDNSSA/DDNRA. 



V y 



nitlen 



htimber of 60-bit words in the NIT. Should be (n+l)*10 
where n is the total number of N«i connections the 
application will support. Note that one is required for 
each anticipated TCP, IP, and TELNET connection, plus 1 
connection if the SMTPxxx interface is used, plus 1 
connection if the FTPxxxx interface is used, plus 1 
connection for DDN registration, plus the number of 
application-specific connections to be supported. 



■v_, 



net 



Array to be used for the Network Control Table. 



nctlen 



r*jmber of 60-bit words in the NCT. Should be n*TBS where 
n is the same as for nitlen, TBS must be at least ??? 
words long, but can be longer if publication-specific 
entries have been defined. 



sysflag System Application flag. Should be true if the 
application does QTxxxx and/or DDNPUT/DDNC£T calls in 
addition to DDN Interface calls (for example, TCPxxxx, 
FTPxxxx). Examples of this are FTPI.FTPS. 



\J 



no wait 
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f y 3.8.3.1.5.8 End Single Connection - DDN EMDT \y 

CALL DDhCNDT (acn, no_wait) 

acn Connection number to be closed. 

no_wait Boolean value, if true, causes routine to return 
iiTKTKBdiately after issuing request. 

3.8.3.2 DDN Host Name Table 

The Gateway name server function shall access the DDN host name table. This 
table is maintained as a file, DEWNAME under un=LIBRARY, with public read 
access. The file is initially created as part of the Gateway installation 
process with a sir^le entry. This entt-y identifies the Network Information 
Center host where the real host name table is maintained, as defined in 
RFC-810. Whenever the DDN supervisor is initiated, it checks to determine if 
m~Jj the file is the installation file or a full narre table file. If only an \j! 
installation file, the Supervisor will automatically initate an FTP request 
to acquire the file. The network administrator can obtain updated cc^ies by 
terminating the Supervisor, purging the file, and re-starting the Supervisor. 

3.8.3.3 Jvtetwork Access Method 

The Gateway shall use Network Access Method (NAM) Application Interface 
Program (AIP) interfaces to est^lish connections and exchange data between 
AI, Supervisor, and DDN/C170 Gateway. 

3.8.3.4 Network Definition File 

G/W shall define its NAM application parameters via NDL configuration 
directives. The directives used are defined in subsection 3.8.8. 

o o 
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\(J) 3.8.3.5 Operator Interface (|"1' 

FTP shall allow the operator to exercise some control over which messages are 
written to the log file. The following are the K-display HOP commands used to 
control message wiring to the log file. 

K.DE = FTP Write error messages only to the log file 
K.DB = FTP Write detoug and error messages to the log file 
K.RS = FTP Write statistics, detoug, and error messages to the log 
file 

Error messages are always written to the log file regardless of any operator 
intervention. 

If the application has been loaded using hETIOD, the K.RS corwnand will also 
restart AIP statistical gathering. 



V 



J 



3.8.4 Internal Interfaces 

The following subsections describe the interfaces between the major 
components of DDN Gateway. The internal interfaces identified are: 

implication Interface to DDN/C170 Gateway 
Application Interface to DDN Supervisor 

3.8.4.1 Pfplication Interface to DDN/C170 Gateway 

The application interface to DDN/C170 gateway interface consists of packets 
of data, passed via a NAM connection. Data packets sent from AI to G/W 
contain data provided by the a|:^lication in TCP/IP/TELNET primitives along 
with a primitive identifier and are destined for TCP/IP/TELNET in the MDI. 
Data packets sent from G/W to AI contain data provided by TCP/IP/TELNET 
indications along with an indication identifier and are destined to an 
application program. 
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J A NAM connection exists between the Gateway and each AI in an application V>^ 

that has registered for host protocol services. An additional connection 
exists for each TCP, IP, or TELNET connection, whether est^lished or 
pending. 

The following interface conventions are defined for data passed between the 
MDI-resident Gateway and the C170 Interface routines. In the discussion, a 
byte always refers to a CDOET 8-bit byte; a word always refers to a CYBER 
60-bit word. 

a. A message sent between MDI and C170, in either direction, will 
consist of a header part and an optional data part. The header part 
will contain information about the message length, 
primitive/indication type, and most of the parameters to or from the 
primitive/indication. The data part will be actual data. Since 
most primitives/ indications do not include data buffers, most 
indication/primitive messages do not contain data parts. ^»v 

O ' o 

b. The header part will always be a multiple of CYBER words. This 
implies that the header will always be a multiple 15 bytes and a 
multiple of 2 words. 

c. The data part will always be a multiple of CYBER words also, just 
like the header. If the actual amount of data is less than a 
multiple of 15 bytes, the message will be padded with zero bytes. 
The actual data length will be stored in a field in the header. 
There is no requirement on the number of bytes of actual data. If 
the header plus data size exceeds the maximum NAM block size then a 
multi-block message will be used to send the data. Whether BIP does 
this automatically or whether gata^jay will have to do the blocking, 
in an MDI-to-C170 transfer, is unknown at this time. In a 
C170-to-MDI transfer, NAM does not do blocking and so it must be 
done by the interface routines. No limit is to be placed on the 

maximum data buffer size (other than actual machine resource or ^^ 
\^ operating system limits). ^mt 
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d. No field within a header part will cross a CYBER word boundary. 
That is, every field must be conpletely contained in a 60-toit block 
(7 1/2 bytes). The position of a header field within a CYBER word, 
and its size, can be chosen according to the convenience of the 
gateway and indication/primitive data structure requirements, since 
SYMPL can be used to arbitrarily define field position/size. Unused 
filler bits must be explicitly defined in the CYBIL definition of 
the interface; they should not be defined in the SYMPL definition. 

e. Messages from C170-to-MDI are either primitive-requests or 
indication-responses. Messages from MDI-to-C170 are either 
indication-requests or primitive-responses. For each request 
received, exactly one response must be returned. No more than one 
unacknowledged (that is, no response received) request can be 
outstanding at each end of the interface. Note that the MDI and 
C170 issue requests asynchronously, so the C170 can receive an 

""^1 indication-request from the MDI while waiting for a '"^^ 

primitive-response, and the MDI can receive a primitive-request 
while waiting for an indication-response. 

f . The header field always contains the following minimum information: 

1) Primitive/Indication identifier (1-7 characters which match the 
C170 interface routine nane). 

2) Block number. This is a 16-bit modulo integer that is 
incremented by the sender each time a request is sent. The 
receiver will always check this number against the previous 
number received to determine if blocks have been lost. The 
initial 'previous' number (that is, when no block has yet been 
received) is zero. If gateway receives an out-of-order block, 
it will ignore it and return an error response. If the C170 
receives an out-of-order block, or if it receives an error 

Oi response for an out-of-order block, it will reset the connection |^\ 

and return status to the user. ^^ 
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f ; 3) Return status (always zero for request, non-zero for re^Donse if \y 

an error) . 

4) Number of header bytes. This is required due to some 
variable-length fields in the header (that is, IP Timestamp). 
If a field is variable, there must be a corresponding field that 
^^ecifies its length. 

5) Number of actual data bytes in data part (zero if no data). 

6) Primitive/Indication parameters (except data buffer), where 
output parameters are not defined in the rec^est but are 
returned in the response along with the original input 
parameters. Therefore, the format of the header is identical 
for a request and its corresponding response, 

g. When the C170 first establishes a connection with MDI, a standard 
^p application identification package will be supplied that ictentif ies \y 

the application name, protocol type, and version number. Gateway 
will verify this connection info. This packet will be defined in 
another ERSIU. 

3.8.4.2 Application Interface to DDN Supervisor 

The apH^lication interface to DDN Supervisor interface consists of rec^jests 
and responds passed via NAM connections, with the recpjests sent by AI and 
responses returned by the Supervisor. The requests are for registration, 
nanre translation, and message logging with associated data supplied by the 
application. The responses from Supervisor contain rec^jested information and 
reply codes that correspond to the request. 

A Wh connection exists between each instance of a AI in a registered 
application and the Supervisor. 

o o 
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^J 3.8.5 &rcM-s and Error Recovery (O) 

3.8.5.1 Supervisor Failure and Recjovery 

The DDN Supervisor shall self-start upon failure. A dunp shall be taken of 
the failed job prior to re-start and the failure time shall be logged. After 
two consecxjtive failures within 10 minutes, the re-start procedure shall 
issue a NAM operator alert and refuse all subsec^jent calls. The problem must 
then be corrected and the Supervisor manually re-started. Applications 
registered at the time of the failure shall be notified via the 
'not_registered' reply; subsequent action is application dependent. 

3.8.5.2 DDN/C170 Failure and Recovery 

The Gateway shall follow standard CDONET conventions for process failure. 

Applications using the TCP/IP/TELNET services at the time of the failure 

shall be notified via the 'networkjjnavailable' reply; subsequent action is 
application dependent. 



\^j 



3.8.6 Data Strxjotures 

Gateway data structures are TBS. 

3.8.7 EcMipaent Configuration 

The Gateway CPCI has no special equipment configuration requirements. 

3.8.8 Installation 

The following subsections define the installation procedures and parameters 
for Gateway. 



V. .y' 
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3.8.8,1 G/W Installation Procedure 



q/W is installed using the DDNGW build procedure and build verification is 
performed using the VDOaI procedure. DDNGW should be treated as a Group 3 job 
as defined in the NOS Installation Hanctoook. The G/W product PL is 
inaintained in MODIFY format. The following files are created or updated by 
the build procedure: JOBGW, DDNNAME, DDNLIB (updated). 

3.8.8.2 G/W Installation Parameters 

The following installation parameters can be tailored for specific sites. 
They are located in common deck COMVIPR. 



o 



IPGCTO Gat®^Jay Connection Timeout. This is the maximum time in seconds 
that G/W will wait for a ranote host protocol to respond to a 
connect request. After this period, the connection will be 
^aorted. The default is 600. 

IPMBUF Maximum Buffer Size. This is the buffer size used for hot 
pro tool transfers. The minimum size is the NAM downline block 
size (255 words default). The default value is 10248. 



o 



LOGMSG Message logging category. This defines the level of messages 
normally logged, barring operator intervention. The possible 
values are: 

= log error messages only (the default) 

1 = level + debug messages 

2 = level 1 + statistical messages 



O 
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'\^p The following modify symbols can be specified using the *DEFIlsE directive to \j) 
influence the G/W build process: 

DEBLXa If defined, G/W will generate AIP trace messages. 

If^ If defined, the G/W listing will contain Internal Maintainance 
information. 

STATS If defined, G/W will generate AIP statistics messages. 
3.8.8.3 hkstwork Startup Master File 

The following directives must be placed in the Network Startup Master File if 
autonriatic initiation of G/W is recfjired. 






JOB(JOBDDNS,DDNS) 

^y 3.8.8.4 Network Definition File Directives 

The following table' lists the Gateway mockjles and their configuration 
parameters: 

Number of 

Copies Request 
Ni!!»§ Description (MXCOPYS) Star table Privile ged 

DDNS DDN Supervisor 1 yes yes 
DDNA DDN User any(i) no no 

^^lication 
DDNG DDN Gateway 1 no yes 

(this will eventually reside in CDCNET and will 
rec^ire X.25-style INCALL/OUTCALL directives) 



■•^....y 
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^ Additionally, Gateway ai:plication users tnust provide OJTCALL directives to \^ 
G/W for their applications. 

3.8.8.5 Gateway Transmittals 

3.8.8.5.1 Gateway/C170 Transmittal 

FTP/SliTP/CDCNET GW transmittals all depend upon the installation of this 
transmittal. 

a. DDN 6ata<ay C170 Program Library (EXa^Jnnnn). This is an UPDATE 
formatted program library containing the Gateway C170 interface 
routines, DDN Supervisor, and common code used by more than one DDN 
corponent. The format of this program library is described below. 
The following object is generated from this PL: 

Name Type Location Descr iption ^^^^^^ 

o o 

DDNS Program Systan DDN Supervisor 

DDNTEXT SYMPL Text None DDN Common SYMPL Declarations 

DDNLIB Library System DDN Application Interface Library 

NAMSTRT Procedures un=NETOPS NAM Startup Proc. UJadate for DDNS 

b. DDN C170 Gat^May Installation procedure (DDNGW). This procedure 
follows DECKOPL conventions to install the DDN C170 Gateway. 

c. DDN C170 Gateway Installation Verification procedure (VDDNGi^). This 
procedure is to be executed on a na^Jly-built system to verify that 
DDN C170 Gateway has been properly installed. It does not verify 
that the Gateway actually works. It follows DECKOPL verification 
conventions. 



o o 
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\J 3.8.8.5.2 Gateway/CDCNET Transmittal \J' 

No other transmittal can depend upon this transmittal. 

a. DDN Gateway CDCNET Program Library (DGNnnnn). This is an SES MODIFY 
formatted PL containing the Gateway CDONET-resident program and 
command processors. The decks in this PL are incorporated into the 
CDCt^ET PL by a build procedure; it is not used stand-alone. The 
following object is generated from this PL: 

Naf"s Type Location Description 
(TBS) 

b. CDOET GW Installation procedure (Dl^lGN). This procedure follows 
TBS CDCNET build procecbre conventions to install the Gateway in the 

^ ^ CDCNET PL and system. 

c. CDOCT GW Installation Verification procedure (VDE^vOnJ). This 
procedure is to be executed on a newly-built system to verify that 
the Gateway has been prqaerly iretalled. It does not verify that 
the gateway actually works. It follows TBS CDCNET verification 
conventions. 

3.8.8.6 Program Library Structures 

3.8.8.6.1 R_ Structure 

a. Where deck lists are described as 'organized', it means that the 
decks are arranged in a SIMPLE manner logical with the structure of 
the program. For exartple, the main program followed by all primary 
routines in alphabetical order followed by all minor routines in 
alphabetical order. If no structure can be identified, 'organized' 
deger^rates to 'alphabetized', never to 'random' or 'cooplex' . 
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b. DDN Gateway/C170 PL Structure 



o 



INFO 
HISTORY 

[alphabetized ccxnmon decks] 
-TEXTS- [contains *OWEOR] 
DDNTEXT 

-LIBSYMP- [contains *OWEOR] 
[SYMPL library routines, alphabetized] 
-LI8C0MP- [contains *CWEOR] 
[COMF¥^SS library routines, alphabetized] 
-SYMPL- [contains *CWEOR] 
-DDNSSYMP- [errpty deck] 
[DDN Supervisor SYMPL routines, organized] 
-COMPASS- [contains *OE0R] 
-DDNSCOMP- [empty deck] 

[DDN Supervisor COMPASS routines, alphabetized] 
(j -NAMSTRT- [contains *CWEOR] \J 

JOBDDNS 
-ENDPL- [empty deck] 

NOTE: All non-library SYMPL/COMPASS decks are compiled into a large 
library. The DDNS main program is loaded using LIBLOAD from 
that library, 

c. Inter-Component Common Decks 

DDN System-Wide 

COMVDDN DDN General Runtime Interface Definitions 

COMVDIP DDN Systan Installation Parameters 

COMVFET CIO FET Definitions 

COMVFIT CRM FIT Definitions 

COMVIPC IP Interface Definitions 
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COMVNCT DDN NOT Definitions (Tj) 

COMVSYS CYBER System Definitions 

COMVTCP TCP Interface Definitions 

COMVTEL TELhET Interface Definitions 

DDN Gateway 

COMVASC DDN Application to Supervisor Interface 
COMVGIP DDN Gateway Installation Parameters 
CC3MVMDI DDN MDI to C170 Interface 

3.8.8.6.2 PL Structure 

a. Where deck lists are described as 'organized' , it means that the 
checks are arranged in a SIMPLE manner logical with the structure of 
the program. For example, the main program followed by all primary 
routines in alphabetical order followed by all minor routines in 

s^ J alphabetical order. If no structure can be identified, 'organized' l 

degenerates to 'alphabetized', never to 'random' or 'corrplex'. 

b. Gateway/CDChO" PL Structure. 

(TBS) 

c. Inter-corrponent Common Decks. 

(TBS) 

3.9 Network Operating System (NOS) 

The following list shows the ^Dplicatior© which initiate 3.9.??.?? 
??????????? 

The following list shows the applications which initiate connections, and the 
number of connections that may be initiated from each instance of an 



J 
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O) application. This is used as the basis for the development of INCALL/OUTCALL 
directives and test configurations. 

pryp _> FTPI (1) SrfTP -> SMPI (1) 

FTP -> DDNS (1) StiTP -> DDNS (1) 

FTPA -> FTPI (1) SMPA -> SMPI (1) 

FTPA -> DDNS (1) SMPA -> DDNS (1) 

FTPI -> DDNS (1) SMPI -> DDNS (1) 

FTPI -> DDNG (n) SMPI -> DDNG (n) 

FTPI -> FTPS (1) SMPS -> SMPI (1) -' 

FTPS -> DDNG (1) DDNA -> DDNG (n) 

DDNA -> DDNS (1) 

NOTE: The nuntoer following the connection is the number of connections per 
instance of the application PAIR. For exanple, there can be many 
instances of an SMTP, but there is only one connection per instance. 
The nurrber of instances of each application has been identified in the 

g^ -previous table. The application before the arrow is the application ^ 

^"*^ that initiates a connection. 

3.9.1 NOS Abstract 

NOS version 2.4.2 will be the operating system for DDN. A pre-release is 
expected in May 85 with a formal release in Aug of 85. 

3.9.2 NDS Modificaticwis Installation 

3.9.2.1 NOS Modifications Transmittal 

FTP/SMTP/C170 GW/CDCNET GW transmittals all dqoend upon the installation of 
this transmittal. 
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(Q) a. File containing modsets to NCDS OPL. Changed decks are currently (Q; 
MODVAL and COMTNAP. At a minimum, MODVAL and NVF (a NAM module) 
must be re-built for these modsets to take effect. The modset file 
is in standard MODIFY multi-record format, according to standard. 
These modsets can be installed using the standard DECKOPL NOS 
installation procedure. 

b. NOS Mods Installation Verification, procedure (VDDfvNOS). This 
procecLire is to be executed on a newly-built system to verify that 
the NOS mods have been properly installed. It does not verify that 
the modsets actually work. It follows DECKOPL verification 
convent ior©. 

c. File containing modsets to NAM. Changed decks are currently 
QTRWIT, QTGET and QTOPEN. At a minimum, these decks must be 
re-built for the modsets to take effect (note that QTRMNIT must be 
assembled prior to assembly of the others). The object code from 
these decks resides on libraries NETIO and hETIOD. The file is in 
UPDATE SLASHPL format, according to standard. These modsets can be 
installed using the standard DECKOPL NAM/NAMD ii^tallation 
procedure. 

d. NAM Mods Installation Verification procedure (VDDfsMAM). This 
procec*jre is to be executed on a newly-built system to verify that 
the NAM mods have been properly installed. It does not verify that 
the modsets actually work. It follows DECKOPL verification 
conventions. 

3.9.2.2 PL Structure 

a. Where deck lists are described as 'organized', it means that the 
decks are arranged in a SIMPLE manner logical with the structure of 
the program. For example, the main program followed by all primary 
routines in alphabetical order followed by all minor routines in 






o 



k. 



y 
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alphabetical order. If no structure can be identified, 'organized' 
degenerates to 'alphabetized', never to 'random' or 'conplex'. 






b. NOS Modifications PL Structure. 



(TBS) 



c. Inter-Component Common Decks 



DDN System-Wide (defined in DDNTEXT) 



c 



COMVDDN DDN General Runtime Interface Definitions 

CC3MVDIP DDN System Installation Parameters 

COMVFET CIO FET Definitions 

COMvFIT CRM FIT Definitions 

COMVIPC IP Interface Definitions 

CCnMyj DEW NCT Definitions 

COMVSYS CYBER System Definitior^ 

COMVTCP TCP Interface Definitions 

COMVTEL TELNET Interface Definitions 



^liyil/F- 



DDN Gateway 

COMVASC DDN Afi^lication to Supervisor Interface 

COMS/GIP DDN Gateway Installation Parameters 

COMVMDI DDN MDI to C170 Interface 



FTP 



o 



COMVAPC FTP Application to Protocol Interpreter Interface 

COMVFTP FTP Definitions 

CCDWIPF FTP Installation Parameters 

COMVPFC FTP Protocol Interpreter to File Server Interface 

COMVSSJ FTP NOS Validation Interface 



o 
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COMVAPC SMTP Appliication to Protocol Interpreter Interface' 
COMVIPM SMTP Installation Parameters 
COMVSIP SMTP Def.initior© ^ 

3.10 Distributed Communications Network Software CDCNS) 

3.10,1 DCNS Abstract 

DCNS is CDC's Standard procbct communication software that will reside in the 
Mainframe Device Interface (MDI), Terminal Device Interface (TDI), and 
Network Device Interface (NDI) hardware. For DDN, the NDI will be 
supplemented with X.25, TELNET, TCP, and IP software in ooffpliarK« with 
requirements. 



3,10.2 CONVERT ModificaticflTs Transmittal 

CDCNET GW transmittal depends upon the installation of this transmittal, 

a. File containing modsets to CDCWET PL. Changed decks are currently 

TBS (incl, TCP, IP, TELNET, B I P/SVM). The modset file is in iT 
standard SES v MODIFY multi-record format, according to standard.- IQ 
Installation of these modsets is TBS after CDCNET build conventions rtroo 
are known, 

b. CDCNET Mods Installation procedure (DDNCON). This procedure follows 
TBS CIXJNET build procedure conventions to i retail the modsets in the 
CDCNET PL and system. 

c. CDCNET Mods Installation Verification procedure (VDDNCON). This 
procedure is to be executed on a newly-built system to verify that 
the CONVERT mods have been properly installed. It does not verify 
that the modsets actually work. It follows TBS CDCNET verification 
conventions. 
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3.10,3. PL Structure 






a. Where deck lists are described as 'orgarazed' , it means that the 
decks are arranged in a SIMPLE manner logical with the structure of 
the program. For example, the main program followed by all primary 
routines in alphabetical order f 01101-^ by all minor routines in 
alphabetical order. If no structure can be identified, 'organized' 
degenerates to 'alph^setized' , never to 'random' or 'complex'. 

b. CONVERT PL Structure. 
(TBS) 

c. Inter-component Common Decks. 
(TBS) 

f\ 3.11 CDOET Hardware f^ 

3.11.1 ax>ET Hardware Abstract 

The CDCNET hardware consists of a device termed a Device Interface (DI). The 
DI is a modular and configurable microprocessor,; Depending on the 
configuration a DI may be a: 

MDI - Mainframe Device Interface, which connects the DI to a CYBER. 

NDI - Network Device Interface, which acts as a packet switching device 
to transfer data between network elements. 

TDI - Terminal Device Interface, which is used to interface terminals to 
the network. 
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\Jf The following minimum DON hardware is ■ required for a DDN CYBER Host 

Interface: 



Qty^ Part_No^ Name PI Variant Descriptjkon 



■■*., >•■ 



3 2601-003 DI 

1 2603-001 SW 

2 2604-001 SMM 
1 2606-001 PMM 

1 2607-001 MCI • 

3 2608-002 ESCI 

2 2609-001 CIM 
1 2610-016 LIM 
1 2612-017 LIM 



l-H)I,NDI,TDI Device interface: includes masfefr 
prg>pessor board, power supply, oabitTig; 
and internal bus system. 



NDI 

MDI,TDI 
MDI 
MDI 



512K byte main naemory module 
1024K byte main memory module 
Private memory inodule 
Mainframe channel interface 
MDI,NDI,TDI Ethernet system communication interface 
NDI, TDI Communication interface module 
NDI RS-449 line interface module 
TDI RS-232 line interface module 



I) 
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